Version numbering post 1.0

[Robert Collins]

On Thu, 2007-08-09 at 18:53 -0700, Wichmann, Mats D wrote:
> bazaar-bounces at lists.canonical.com wrote:
> > I think different releases have different consequences for
> > users, such as
> > 
> > * this fixes a serious bug; everyone should upgrade now
> > * this fixes some bugs and has internal cleanups; if you're not
> > affected by those bugs there's no rush to upgrade
> > * this is much faster; if you want that then upgrade
> > * this has a new default format; if you upgrade to this then older
> > clients won't be able to understand you
> > * this has a great new feature
> > * this has a lot of changes
> > 
> > Our releases are pretty solid and well run, so it's reasonable for
> > people to upgrade on every release, but as Ian says for various
> > reasons not everyone will want to.  So we need to have some way to
> > help people make their decisions on their own criteria.
> 
> The main issue we've run into is that people run a specific
> distribution and are anything from uninterested to totally
> unwilling to install anything other than a distro-provided
> package of bzr.  So if you're running Debian Stable, say,
> you're stuck on 0.11 for a "very long time".

And this to me says more about managing our communication to distros -
about what versions to include, and when to do an update to the version
in a stable release of the distribution, than about our version numbers.

We really have limited bits available in version numbers. I'd tackle
this by deciding what we want to signal via versions, and what via
changelogs.

cisco for instance include a huge amount of detail in their version
strings. And as a customer its damn hard to tell what version to grab by
the string alone - you get feature sets, you get engineering releases vs
all model vs specific model vs ....

I think the key things to message are:
 - 'stability' in an overall 'is bzr ready to adopt' sense. E.g. close
to or greater than 1.0
 - 'release' vs 'in development'
 - 'bugfixes only'

To date I think we've done this moderately well, though we haven't
signalled 'ready to use' well enough.

So I think:
X.Y.Z where:
 X is 0 for now, and 1 soon.
 Y indicates how close to the next X we think we are, from 0-99.
 Z indicates a bugfix only change for a given X.Y - by which I mean no
command changes, no library API changes - e.g. something that is
*really* safe to drop into an existing environment.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070810/4c52c6d9/attachment-0001.pgp