Version 1 (modified by cotto, 6 years ago)

initial version, mostly copy/paste from Allison's proposal on parrot-dev

After much discussion, the following scheme was proposed by Allison and accepted by the majority of Parrot developers:

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.