Release timing

[Jake]

> I've proposed a solution to this - have some releases be supported longer
>  than others.  Some people need long-term stability (ala RHES).  Have
> other releases be supported until two releases have been made.  So if 2.20
>  became a "long-term support" release, it would continue to be supported
> for three years.  During that time, six releases would come out (two per
> year).  So at any one time two "short term" releases would be in support
> and one or two "long term" releases.  This way there would never be five
> branches being supported at once and usually there would only be three -
> the long term one and two short term ones.

I think this is where the branch maintainers thing that Dave was talking
about may help things. We set a minimum support timeframe (6 months
bugfixes, 18 months security) and if a branch maintainer wants to carry
bugfixes for a year, so be it. If they want to support security fixes for
3 years, that's their choice. This would be ideal for situations where,
for example, there's a Debian package on a stable version of Debian that
only allows security fixes. The branch maintainer can keep up with
security on that branch until that version of Debian hits EOL. We should
set a strict policy, IMHO, for branch maintainers that no new features
land on a branch.