Brave new (1.0) world.

[Allison Randal]

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