| | 1 | After much discussion, the following scheme was proposed by Allison and accepted by the majority of Parrot developers: |
| | 2 | |
| | 3 | 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: |
| | 4 | |
| | 5 | {{{ |
| | 6 | 1.0 (March, deprecation point) |
| | 7 | 1.1 (April) |
| | 8 | 1.2 (May) |
| | 9 | 1.3 (June) |
| | 10 | 1.4 (July, deprecation point) |
| | 11 | 1.5 (August) |
| | 12 | 1.6 (September) |
| | 13 | 1.7 (October) |
| | 14 | 1.8 (November) |
| | 15 | 1.9 (December) |
| | 16 | 2.0 (January, deprecation point) |
| | 17 | 2.1 (February) |
| | 18 | 2.2 (March) |
| | 19 | 2.3 (April) |
| | 20 | 2.4 (May) |
| | 21 | 2.5 (June) |
| | 22 | 2.6 (July, deprecation point) |
| | 23 | 2.7 (August) |
| | 24 | 2.8 (September) |
| | 25 | 2.9 (October) |
| | 26 | 2.10 (November) |
| | 27 | 2.11 (December) |
| | 28 | 3.0 (January, deprecation point) |
| | 29 | ... |
| | 30 | }}} |
| | 31 | We would keep the sub-minor version numbers, but for bug/security fix releases, rather than for monthly releases. |
