Version numbering post 1.0

[Ian Clatworthy]

Aaron Bentley wrote:

> I don't think that "emotional version numbers" fit very well with our
> development practices.  Really, for suggesting high maturity, 0.9.10
> would be better than 0.90.

It's an interesting idea. I'm not sure why you picked .10 vs some other
number but I guess it doesn't matter given that's not your main point,
right?

What we do post 1.0 is arguably a separate issue but we probably need to
 talk about it a bit more before we get there. And if we're compfortable
about that, perhaps that impacts what we do pre 1.0? The $64M question
is whether we intend to keep releasing every month post 1.0 and, if so,
what makes sense version number wise.

I must say how mega-impressed I am about how stable bzr.dev has been
since I've joined the team. It has *absolutely* nothing to do we me
joining, of course - I'm sure it was pretty damn good for a long time
before that! I'm sure a lot of it has to do with using Bazaar/DVCS, test
suites, reviews + PQM, i.e. the process+toolset "defends" the trunk
*really* well against instability.

So, on the one hand, the traditional "rules" about product lifecycles
and needing to have instable periods to keep velocity just don't seem to
apply because of our DVCS-enabled process. On the other hand, perhaps
lifecycles are driven as much by user needs for stability as engineering
limitations?

My feeling, perhaps too conservative, is that 12 "flat" releases per
year will prove too much for teams to mentally track w.r.t. API
compatibility, plugin compatibility, etc. Yet unless we're releasing
once per month, saying "wait for the next release" vs "here's a
sanctioned point release to fix bad bug X" won't cut it. In other words,
we need a 3 level version numbering scheme, not 2. Of course, that 3rd
level could just as easily be the normal monthly release.

In the spirit of giving everyone a suggestion to enjoy shooting down,
:-) here's a suggestion for post 1.0:

1. We use a 3 level scheme x.y.z
2. We use names like x=mega, y=major, z=minor
3. We release a major version every 3 months and promise API stability
   for 2 major releases (6 months)
4. We release a minor version every month just like now though the
   minor version could be a little more interesting that normal
   minor releases, e.g. not just emergency bug fixes but perhaps
   some improvements as well
5. We only change the mega number if serious incompatibilities
   across versions are needed.

To put it another way, we stick with monthly releases but superimpose a
quarterly cycle for the purposes of turning on new formats by default,
deprecating APIs, etc.

Ian C.