bzr 1.18rc1 source frozen

[Martin Pool]

2009/8/11 John Arbash Meinel <john at arbash-meinel.com>:
> It was unclear to me whether 1.18 is part of the new release process or not.
>
> If it *is*, then I think the announcement should be:
>
>  2.0beta1 has gone gold, please build installers so that we can
>  announce general availability
>
> Calling it 1.18rc1 means (to me) that 1.18 is going to be the last
> release in the old system.

You're right, this is a bit half-and-half.

I think the new scheme has been agreed and there's no good reason not
to start doing it now.

When we [I think Robert and I] talked about this the other day there
was some concern that marking it 2.0beta before setting the default
format would be confusing.  However, that's really still looking at it
the old way, rather than the new scheme in which we plan to call them
betas quite early in the cycle.

I think we should just change to the new one, therefore call this a
2.0beta.  I don't know if I quite care enough to re-roll this release.
 How about if in one week from now, we do another release from the
trunk and make that 2.0beta1?

> My personal understanding is that in the new system:
>
> 1) We will have release candidates for 6-month stable releases
> 2) We will *not* have release candidates for 1-month "beta" releases
> 3) We will release a 1-week follow up to a "beta" release as many times
> as necessary, just like we would have done in the past with release
> candidates until final was good enough.
>
> The main difference here (versus how we did all releases <=1.17) is that
> the beta releases don't have a follow up "yes that release we did is
> really good, let's mark it -final".
>
> 4) We will make an internal announcement once the source tree is
> finalized, PQM has merged the version change, and tarballs have been
> uploaded.
> 5) The installers for windows, mac, and PPAs will be built.
> 6) Once installers are available, we will send a bzr-announce@
> announcement that the latest version of bzr is available, and this is
> where you can get it from.

That's correct.

(I'll try sometime soon to update the document with the thread
consensus and propose that to merge into bzr.dev developer docs.)

> I personally don't feel any need to have an *rc* period for the windows
> installer. I'm perfectly fine with "release X.YbetaZ-windows1" and then
> "X.YbetaZ-windows2" if we find problems. The same way we are thinking to
> do beta releases if there are problems with the bzr code. (step 3).
> I would really *like* to not have to do a spurious extra build on every
> release. If past history holds true, I'll be doing them anyway because
> of bundling issues, but at least they won't be mandated by our release
> process.

Right,  builds with no changes but the version number are fairly clearly waste.

Gary said earlier in this thread that he did want a source freeze to
give time for Windows installers before the general announcement, but
that's orthogonal to having an rc.

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