Version numbering post 1.0

[Alexander Belchenko]

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

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.

IMO 3 months is fine.

- --
[µ]

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

iD8DBQFGvVC2zYr338mxwCURAlNqAJ0Xwt+Pvr+Srl7hZopKfFbi9HtZdACeKqlb
i8O1Ahlm76v/gxVkITiNKDQ=
=Jc2l
-----END PGP SIGNATURE-----