monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] netsync flag day justifies bumping version number t


From: Daniel Carosone
Subject: Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Date: Wed, 26 Aug 2009 12:52:23 +1000
User-agent: Mutt/1.5.19 (2009-01-05)

On Tue, Aug 25, 2009 at 08:24:24PM -0500, Timothy Brownawell wrote:
> How long would we want to try to stay compatible with old versions,
> maybe 2.5 or 3 years? Debian releases last 4 years now (2 as stable, 2
> as oldstable), and Ubuntu LTS releases happen every 2 years and are good
> for 3 or 5 years. RHEL versions are apparently supported to some degree
> for 7 (!) years.

I'm really struggling with this whole concept.  It's come up both in
this thread, and in zwol's about dependencies.  

I don't see why an operating system choice (let alone which variant of
an operating system, or which variant of the variant) by an end user
matters.

For building new versions of the application on that platform, with
minimal fuss in terms of additional dependencies, as a common courtesy
to maintainers within reasonable bounds, sure.  That's just a general
portability goal. Providing support guarantees, especially outside
those reasonable bounds, surely is the support vendor's risk,
responsibility and therefore business model.  

I don't get why some vendor's OS support cycle dictates the
application's cycle.  Whatever the numbers above and today, do ours
change if a new vendor appears with bigger numbers?  Are we really
saying that just because someone still runs "pink pantyhose 11", which
was originally shipped when monotone 1.1 was current 11 years ago,
they will also still be running monotone 1.1?  Must every software
project/author (monotone, botan, sqlite, etc) wear those pink
pantyhose as a result? 

There seem to be contradictory requirements between the two threads,
and moreso the discussion seems to be heading that we're to be
constrained by the intersection of both.  That's especially hard to
swallow when I'm having difficulty understanding why we should be
(heavily) bound by either.

Of course we should avoid unnecessary compatibility breaks between our
own releases, and I encourage the discussion of how we might do so
before making our next release.  Ultimately, upgrades will be required
if you want new features, including new features adopted by others in
the broader community of clothing colours, and db migrate is our
upgrade path.

--
Dan.

Attachment: pgpDTsdGIwWqq.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]