Version numbering post 1.0

[casret]

On 8/9/07, Matthew D. Fuller <fullermd at over-yonder.net> wrote:
>
> On Fri, Aug 10, 2007 at 02:28:03PM +1000 I heard the voice of
> Robert Collins, and lo! it spake thus:
> >
> > they won't be affected by a change to 0.90 - but the folk that react
> > emotively will be.
>
> Well, yeah.  My point is that *I* react emotively to it, and it's a
> negative emote.  The first version of bzr I used was 0.6, and I'm glad
> of that, as I once had occasion to look back and try and find out when
> 0.5 was released...
>
>
> "Wow, Solaris 7 is out already?  Seems like I just installed 2.6..."


I feel like you guys are underestimating your users here.  We are also
developers.  We understand that release minors are usually just incremented
and are not going to read too much into them.  I think in terms of
communicating to your users you need a major (especially that all important
1.0) that represents major incompatible changes.  I think the disconnect is
that there is also a need to know when there is a release that you the dev
team would really like people to use and upgrade to, which is usually what
the minor is for, but in your development cycle is more based on the time.
(Upgrading your SCM every month is a bit heavy from most people).  Maybe
these two concerns should be split:

Major.minor.patch for blessed releases.  (the minor goes up when you want
people to upgrade, patch for critical bugfixes) and a
<major>.<minor>.dev-<date> for the monthly releases, with minor being 1 +
the blessed release.

BTW, once really start the run for 1.0 release, I think the better P.R. move
is to go with the release candidates (1.0.0rc1).  That's a real strong
signal to the community that you really want their help in nailing out the
last bugs and issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20070810/d680d9c8/attachment.htm