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
