[RFC] Releases planning

[John Arbash Meinel]

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

On 10/13/2010 2:02 AM, Martin Pool wrote:
> One specific thing in this that John raised in
> <https://code.launchpad.net/~vila/bzr/rm-tweaks/+merge/38240> (rm
> meaning 'release manager' not 'remove'):
> 
> I think, for us, release candidates are not worthwhile, and they're
> just a waste of work and a source of latency.
> 
> We do find bugs all the time, but we don't often find critical bugs
> that require us to slip the release, and if we do then we have the
> window between code freeze and announcement to make a change.  We do
> get some good testing of betas, and of code and installers before the
> announcement, and I am not convinced there is a large slice of users
> who would test rcs but won't test betas.
> 
> I think basically we should optimize for the common success case which
> is that the .0 release is good.  If we find bugs, we can fix them in
> the .1 release, and if we find very serious bugs we can do a .1
> release quickly.  Users who are very risk averse can and probably will
> just wait a while before upgrading.
> 

IMO, calling it RC1 can be equivalent to beta4, but can also indicate to
plugin authors, etc that we are ready for the final release.

I guess the big difference is that an rc1 delays getting updates into
stable out as final for a month?

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

iEYEARECAAYFAky1yG0ACgkQJdeBCYSNAAMeKQCfR1NJVat+0F6MapLVbpfZ065f
Re4AnAgP24rnQv75FcoEBW8UNIJOPJsT
=WtdP
-----END PGP SIGNATURE-----