On Mon, Dec 6, 2021 at 4:19 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Right. The question that's on the table is how much is the right > amount of maintenance. I think that back-patching user-visible bug > fixes, for example, is taking things too far. What we want is to > be able to replicate the behavior of the branch's last released > version, using whatever build tools we are currently using. So > back-patching something like that is counterproductive, because > now the behavior is not what was released. > > A minimal amount of maintenance would be "only back-patch fixes > for issues that cause failure-to-build". The next step up is "fix > issues that cause failure-to-pass-regression-tests", and then above > that is "fix developer-facing annoyances, such as compiler warnings > or unwanted test output, as long as you aren't changing user-facing > behavior". I now think that it'd be reasonable to include this > last group, although I'm pretty sure Peter didn't have that in mind > in his policy sketch.
Yep, that seems reasonable to me. 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. I don't know that I'm terribly bothered by the idea that the behavior of the branch might deviate from the last official release, because most bug fixes are pretty minor and wouldn't really affect testing much, but it would be a little annoying to explain to users that those branches contain an arbitrary subset of newer fixes, and a little hard for us to understand what is and is not there. That being said, suppose that a new compiler version comes out and on that new compiler version, 'make check' crashes on the older branch due to a missing WhateverGetDatum() call that we rectified in a later, back-patched commit. I would consider it reasonable to back-patch that particular bug fix into an unsupported branch to make it testable, just like we would do for a failure-to-build issue. -- Robert Haas EDB: http://www.enterprisedb.com
