Brave new (1.0) world.

[Stephen Gunnell]

Hi,

>From a consumer point of view this numbering scheme doesn't have much to
recommend. Your major version number should form a contract with your
downstream consumers: When we step the major version number you need to
examine the interface between your product and Parrot. So every one of
your deprecation points should step the major version number if and only
if a deprecation cycle is actually started or completed in that release.
Similarly rolling the minor version  number is a contract that says: We
have not made any changes that will break the API. Check your
workarounds to known issues but beyond that your product will not be
broken.

Now with my professional configuration and release manager hat on I
would be saying that monthly releases are awfully ambitious for anyone
not doing tightly controlled RAD, XP or a similar fast cycle development
methodology. As a configuration manager I would reject this numbering
scheme if it came from any project under my authority.

Cheers,

Steve Gunnell


On Fri, 2009-02-20 at 14:16 -0800, Allison Randal wrote:
> This conversation was heading in a semi-poisonous direction (though 
> certainly not poisonous yet), so I decided it was time to just pick up 
> the phone. chromatic and I talked for ~20 minutes, and came up with a 
> version numbering scheme that resolves my concerns and his concerns, and 
> seems to cover the points from the conversation here.
> 
> The idea is that we keep the yearly major version release and the 
> half-yearly deprecation point between two major version releases, as we 
> planned at the developer summit. But, the only thing that really matters 
> about the version number of the half-yearly deprecation point is that it 
> be predictable. Using minor version numbers for every monthly release 
> makes it predictable:
> 
>      1.0  (March, deprecation point)
>      1.1  (April)
>      1.2  (May)
>      1.3  (June)
>      1.4  (July, deprecation point)
>      1.5  (August)
>      1.6  (September)
>      1.7  (October)
>      1.8  (November)
>      1.9  (December)
>      2.0  (January, deprecation point)
>      2.1  (February)
>      2.2  (March)
>      2.3  (April)
>      2.4  (May)
>      2.5  (June)
>      2.6  (July, deprecation point)
>      2.7  (August)
>      2.8  (September)
>      2.9  (October)
>      2.10 (November)
>      2.11 (December)
>      3.0  (January, deprecation point)
>      ...
> 
> We would keep the sub-minor version numbers, but for bug/security fix 
> releases, rather than for monthly releases.
> 
> Thoughts and comments welcome.
> 
> (I'm about to lose reliable network access, but will check back in on 
> Sunday.)
> 
> Allison
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev