2.1.0b5 or 2.1.0rc1?

Martin Pool mbp at canonical.com
Tue Dec 15 07:26:44 GMT 2009


2009/12/15 John Arbash Meinel <john at arbash-meinel.com>:

> According to our timeline:
>  https://edge.launchpad.net/bzr/2.1
>
> The release in January is meant to be 2.1.0rc1 with a two week
> turnaround into 2.1.0rc2 and 2.1.0 final being at the beginning of
> February. I'm pretty sure Martin put that schedule together so that
> 2.1.0 final will be well in advance of the code freeze for Lucid.
>
> This sounds like a reasonable process to me, though it would mean that
> we would have a fairly short 2.1.0b4 => 2.1.0rc1 cycle. (Which is mostly
> my fault because I injected a 2.1.0b4 that Martin didn't originally have
> planned.)

I do want to get it into Lucid without rushing, because we know that
causes problems and churn that normally outweigh the benefit of any
particular feature.  Though there are many more things we'd like to
finish, I don't think there's anything that's feasible to finish and
solidify by the end of February but not possible to do then.  Also
we'll need more time for plugins to be tested against it.

On the other hand it is wasteful to do the release cycle too often
doing tiny releases.

I feel like the bug fixes we've been landing so far have generally
been pretty safe and we're unlikely to need many attempts at 2.1final.

https://wiki.ubuntu.com/LucidReleaseSchedule

We could push rc1 out to 2010-01-21 (the date currently for rc2) which
would give roughly four working weeks after 2.1b4.  We would then have
four weeks for the Feature Freeze of Lucid (2010-02-18), which would
be a natural time (not the latest deadline) to switch to bugfix-only
changes.

> Since we'll also be having some holiday time in there this seems pretty
> short, but not terrible. I was just updating NEWS, and was wondering if
> I should put:
>
> bzr 2.1.0rc1 (not released yet)
> ##############################
>
> I don't think we want that in the bzrlib.version_info tuple until we
> actually make the release (just like we do 2,1,0,'dev',4 until it
> becomes 2,1,0,'beta',4).

Right.

> Anyway, once 2.1.0rc1 comes out, I'm pretty sure the plan is to start
> 2.2.0b1 as the next 'dev' version.

Right, though I would ask developers to generally focus on fixing bugs
in 2.1 not putting new things into 2.2.  The rules for merges to 2.1
should be similar to what we now have for 2.0 - maybe not quite as
strict but basically no api changes, mostly bug fixes, and looking for
safe patches.

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



More information about the bazaar mailing list