bzr 2.1 timeline

[Martin Pool]

2.0 is now branched, frozen, and on the verge of release.  We're going
to keep supporting that branch with bug fixes for the next several
months at least.  In the mean time, the work on trunk is going to end
up in a 2.1 early next year.  (See
<http://doc.bazaar-vcs.org/developers/cycle.html> for background.)

We want this version into Ubuntu's next major release, which is
probably 10.04 and probably at the end of April.  (They have not yet
announced their schedule afaics, but we can extrapolate from previous
practice.)  The feature freeze is probably about 9-10 weeks before
that, ie the end of February.  To get in before their feature freeze,
and to allow some margin of error, we should plan on freezing the code
that will go into Karmic+1 in early February.  For ease of
calculation, let's say every bzr release happens at the start of a
month.

Therefore:

1 Oct   2.1b1
1 Nov   2.1b2
1 Dec   2.1b3
1 Jan   2.1rc1 --- and 2.1 branches off into a bugfix-only branch,
leaving trunk open for new features towards 2.2
1 Feb   2.1.0

Check my sums?  Are there other deadlines we should take into account?

I'd like to slightly tweak the policy so that for a clearer
distinction from the series, we call the major releases 2.0.0 or
2.1.0, rather than squashing the final 0.

So that gives 5 months of open development (with a couple of weeks
already passed.)

I'm intentionally talking about timeline before I talk about features
because I want to get into a more flowing time-based release system,
where the releases just happen without slippage or angst about what to
put in or not.  I'd like to look at bigger changes in this period, but
also keep the trunk always potentially releasable - not just passing
its tests, but really ready to go at any time in every regard: docs,
testing, packaging, fit&finish.

I think 2.0 will be good, but collectively we've spent a fair bit of
time in recent weeks trying to work out whether it's ready or not, or
what else can fit in.  It's natural, but it's also kind of waste and
I'd like to cut back on it next time.

I am so impressed by how much people have focused on 2.0 bugs
recently.  It'll be a good release.

Now is a great time to:
 * fix bugs that are bugging you, for 2.0.1
 * write specs for future features, and think about larger changes to tackle
 * clear out review queues for things not in 2.0
 * clean up code that's ugly, but potentially an API break

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