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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
