Re: 10.0 - Mailing list pgsql-hackers

> On Jun 20, 2016, at 9:43 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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.

I do, indeed, and here it is:

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.

If you fix a bug on master during development, you can back port that
as well.  But instead of bumping the middle number, you bump the last
number.

Somebody running a version that is three major versions back could
still get the advantage of new features, so long as those new features
are not incompatible.  It's frequently not nearly so easy to run pg_upgrade
as it is to run rpm -U.  You get downtime either way, but the elapsed
time of that downtime is orders of magnitude different.

Someone else running that same version from three major versions ago
can take a more conservative policy, and only upgrade bug fixes, and
forego the back ported features.

You still have one major version release per year.  At that time, you can
also release back-port versions of prior major versions.