bzr 1.18rc1 source frozen

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> 2009/8/10 Andrew Cowie <andrew at operationaldynamics.com>:
>> On Mon, 2009-08-10 at 17:53 +1000, Martin Pool wrote:
>>
>> The source for bzr 1.18rc1 has now been frozen. ...
>> As we discussed in the six-month-release thread, we'll hold off on the
>> public announcement to give people time to make binary packages.
>>
>> Don't you mean "1.18 is released, but we won't tell anyone until the
>> packages exist"?
> 
> That's what I meant.  Did you think I should have said it differently.
> 
>> (I'm sorta surprised to hear you saying it about an RC is
>> all)
> 
> I'm open to suggestions, especially from Windows & other
> binary-oriented users and developers, on whether we should do this for
> rcs or not.  My thinking was: we want RC testing on Windows; if we
> don't have an installer they'll probably ignore the announcement and
> not test it; therefore we should do it for RCs too.  I agree it does
> feel a bit like a rehearsal for the rehearsal.
> 

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.

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.


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.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqATtAACgkQJdeBCYSNAAM4uwCgtTuI9qFccEuAeO1Ua0qYmqIS
LhYAoNaN8vWK3aqC2hUB6zHCstA2V2uG
=1TCd
-----END PGP SIGNATURE-----