Mark Dilger wrote:
> When considering whether to *back port* a change, we typically do so
> on the basis that bug fixes are back ported, features are not. In my
> proposed versioning scheme, you could back port any feature that is
> compatible with the old version, and bump the middle number to alert
> users that you've not just back ported a bug fix, but a feature. Any new
> features that are not compatible don't get back ported.
So instead of having about 5 branches to maintain, we will end up with
5N branches, because we will still have to support the initial .0
branches of each major, plus .1, .2 ... of each major branch?
Granted, we could have major releases not every year but perhaps every 2
or 3 years; non-catversion-bumping patches would still be released
quicker than that, in middle-number-increasing releases. But like
Robert, I don't think that the number of features we could add this way
would be numerous enough to support this idea in the long run.
I think this increases the load on committers many times. Count me out.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services