On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
>> In practical effect that is exactly what your proposal does. You just feel better because you defined when B is
allowedto change even though it never should happen based upon our project policy. And any rare exception can
justifiablybe called a bug fix because, face it, it would only happen if someone reports a bug.
>
> Why are you refusing to acknowledge the difference between features that require a pg_upgrade and features that
don't?
The amount of additional committer work that would be created by
making that distinction would be large. Currently, we're on an annual
release cycle. Every commit that's not a bug fix gets committed to
exactly one branch: master. Inevitably, there are multiple changes
per cycle - dozens, probably - that change initial catalog contents
and would therefore require pg_upgrade.
Suppose we switched to a semi-annual release cycle where every other
release required a pg_upgrade, so once per year same as now, and the
other ones did not. The only way to do that would be to have two
active development branches, one of which accepts only changes that
don't bump catversion or xlog_page_magic and the other of which
accepts changes of all sorts. Every patch that qualifies for the
no-pg-upgrade-required branch would have to be committed twice,
resolving conflicts as necessary.
Also, over time, the number of supported branches would approximately
double. With a five year support window, it's currently about six.
If you had another set of semi-major releases in between the main set
of releases, you'd end up with 11 or 12 active branches, which would
make back-patching significantly more burdensome than currently.
Now maybe you have some other idea in mind, but I don't quite
understand what it is. It's not likely to ever happen that we go
through a whole 12 month release cycle and then get to the end of it
and say "huh, I guess we never bumped catversion or xlog_page_magic".
If that ever does happen, it's probably a sign that nobody is doing
any meaningful feature development any more.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company