Version numbering post 1.0

[Martin Pool]

I think different releases have different consequences for users, such as

 * this fixes a serious bug; everyone should upgrade now
 * this fixes some bugs and has internal cleanups; if you're not
affected by those bugs there's no rush to upgrade
 * this is much faster; if you want that then upgrade
 * this has a new default format; if you upgrade to this then older
clients won't be able to understand you
 * this has a great new feature
 * this has a lot of changes

Our releases are pretty solid and well run, so it's reasonable for
people to upgrade on every release, but as Ian says for various
reasons not everyone will want to.  So we need to have some way to
help people make their decisions on their own criteria.

Different folks will care more about bugs, features, performance, or whatever.

It might be a bit complicated for us to try to have releases which do
only one or the other.  I can imagine saying "please, no format
changes this release" but "any format changes for the next 3 months
have to happen this month" makes things a bit harder to schedule.

Release numbers tend to give them a cue, with x.x.1 implying only bug
fixes.  But it's a bit of a crude instrument, being really only able
to express "big" or "little".  So maybe the names should just be
sequential and we should give clear advice in the release notes
(clearer than in NEWS at present) about the impact of the upgrade.

-- 
Martin