Version numbering post 1.0

[Aaron Bentley]

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

Ian Clatworthy wrote:
> 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?

If we had stopped increasing the minor number at 0.9 and started
increasing the sub-version, we'd be at 0.9.10 now:
0.9 = 0.9
0.10 = 0.9.1
0.11 = 0.9.2
...
0.19 = 0.9.10

> 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.

I think what happens is that there's just as much instability, but it
tends to happen on private branches.

> 1. We use a 3 level scheme x.y.z
> 2. We use names like x=mega, y=major, z=minor

I'm with you this far.

> 3. We release a major version every 3 months and promise API stability
>    for 2 major releases (6 months)

I think this is too restrictive.  I think we should:

4. Release a new minor release every month.  Keep applying bugfixes to
the stable (x.0.0) until (x+1).0.0 at minimum.  Release (x+1).0.0 when
when we want to do a watershed, or when we're just sick of the x.0.z
codebase.  Bugfix releases (x.0.z) are done as needs dictate; this may
be more or less frequent than monthly.

I think this gives version numbers the meanings people expect, and
provides a nice flexible way of working.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGu7nM0F+nu1YWqI0RAr44AJwPZQq+gnp0KiNh/rv6dCXBxTqxKgCfes6O
4HRrsNSDvlPMYh9ms4t8ZWs=
=WYcA
-----END PGP SIGNATURE-----