New 1.14 RC date?

[Russel Winder]

On Thu, 2009-04-02 at 03:32 +0200, Jelmer Vernooij wrote:

> What's the problem with having a -development format available in a release?

For me, nothing.  The argument is that a monthly release cycle of
release quality baz/bzrtools/bzr-svn should not be altered for
development/experimentation material.

> It's clearly marked as a development format, and allows people to see
> what's coming next without having to run bzr.dev. 

Users of releases don't really care about development and technology
previews, they want to use the officially blessed, and known to work,
release material.

Currently we have three levels:

	The version that goes out with an Ubuntu distro
	The currently monthly release (NB this is labelled "stable" !)
	bzr.dev

The first needs to be rock solid and good since it could be in use for
up to 5 years by organizations that only update their system software
for LTS releases.  More likely though it needs to be rock solid because
people will be using it for 6 months without the possibility of update.

The second needs to be solid for those who choose to brave between
Ubuntu updates, but they want a release, not an experiment. (NB this is
labelled "stable" !)

Users of bzr.dev are expecting non-broken software but are clearly the
beta testers for releases.

If this structure needs an extra release level then it needs to be
between bzr.dev and the monthly release, but I am not sure it is needed.
I am finding bzr.dev usable (with the occasional hiccup, but that is to
be expected).

So the core problem is that currently bzr.dev is actually what generates
the monthly releases.  So the conflict is using it for development and
using it as the base of creating releases.  Simplicity dictates the
current set up, but this leads to experimental material getting into the
monthly releases.  Two alternatives:

1.  Create a bzr.dev.extras so that bzr.dev remains the source for
monthly releases but only has the non-experimental stuff.  The
experimental stuff is in bzr.dev.extras and this merges into a branch of
bzr.dev to form the complete experimental whole.

2.  Stay with the current set up but do not change the timings for stuff
that is experimental.  Especially, drop experimental stuff into bzr.dev
at the beginning of a monthly cycle not at the end.  That way there is
at least a chance of not dumping stuff into the monthly releases that is
broken.

In terms of risk management the second of these seems preferable --
minimize infrastructure, require people to realize the monthly release
will contain experimental material but with confidence it won't damage
their set ups.

BTW which version of Bazaar will be in Karmic, what about the following
one?  My worry is that an Ubuntu release will get a broken monthly
release.

And then there is the issue that Ubuntu users are a tiny minority of the
users out there, most people use Windows (sadly), so the really
important thing is to institute a process whereby a Windows installer
gets created along with each monthly release.  
-- 
Russel.
============================================================
Dr Russel Winder                 Partner

Concertant LLP          t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,     f: +44 8700 516 084    voip:  sip:russel.winder at ekiga.net
London SW11 1EN, UK.    m: +44 7770 465 077    xmpp: russel at russel.org.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090402/094c1a45/attachment.pgp