On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >> In practical effect that is exactly what your proposal does. You just feel >> better because you defined when B is allowed to change even though it never >> should happen based upon our project policy. And any rare exception can >> justifiably be 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
