Robert Haas <robertmhaas@gmail.com> writes:
> I guess the point about user-visible bug fixes is that, as soon as we
> start doing that, we don't really want it to be hit-or-miss. We could
> make a decision to back-patch all bug fixes or those of a certain
> severity or whatever we like back to older branches, and then those
> branches would be supported or semi-supported depending on what rule
> we adopted, and we could even continue to do releases for them if we
> so chose. However, it wouldn't be a great idea to back-patch a
> completely arbitrary subset of our fixes into those branches, because
> then it sort of gets confusing to understand what the status of that
> branch is.
Yup, and also confusing to understand whether a given new fix should
be back-patched into the out-of-support-but-keep-buildable branches.
I want to settle on a reasonably well-defined policy for that.
I'm basically suggesting that the policy should be "back-patch the
minimal fix needed so that you can still get a clean build and clean
check-world run, using thus-and-such configure options". (The point
of the configure options limitation being to exclude moving-target
external dependencies, such as Python.) I think that Peter's
original suggestion could be read the same way except for the
adjective "clean". He also said that only core regression needs
to pass not check-world; but if we're trying to test things like
pg_dump compatibility, I think we want the wider scope of what to
keep working.
regards, tom lane
