2.0 support lifetime

[Martin Pool]

On 24 March 2010 16:28, Ben Finney <ben+bazaar at benfinney.id.au> wrote:
> Martin Pool <mbp at canonical.com> writes:
>
>> I was going to enumerate the costs and benefits of continuing support
>> for longer but I think we all have a pretty good idea.
>
> I'm betting that it would still be useful to document that publicly,
> especially for future reference when the policy comes under question and
> the rationales are misremembered.

Heh, ok.  Perhaps we should put it into the release cycle document,
but let's get it straight first.

Benefits of a longer support window:

 * people who want to keep a group of developers all on 2.0 can do so
for longer, while still getting bugfixes
 * similarly for distributions that can take bugfixes into an update
stream, but not major new versions
 * allows you to keep running plugins or other code that is
slow-moving but useful
 * arguably looks good, even if not taken advantage of
 * ...?

Costs:
 * bugfixes must be written against the old branch, or backported;
this may be harder if there is eg nicer test infrastructure in later
branches
 * there is a slight chance of getting different failures as you merge
the fix into different branches
 * each release requires some work to release, announce, and package;
some more of this can be automated but there is still a cost; distro
maintainers may feel obliged to package everything
 * at some point users may be better off upgrading
 * new releases are actually quite stable and users may be better off upgrading

Perhaps we should keep these series active and just release on them
less often (like every 2-3 months), unless there is a critical fix.

I think we need a better flattened form of the tree-structured NEWS
data too.  2.1.1's own news section doesn't look very big but when you
consider it also includes the 2.0.5 fixes it is quite worthwhile.

-- 
Martin <http://launchpad.net/~mbp/>