Re: pg_dump versus ancient server versions - Mailing list pgsql-hackers

On Mon, Oct 25, 2021 at 10:23 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> What concerns me here is that we not get into a position where we're
> effectively still maintaining EOL'd versions.  Looking at the git
> history yesterday reminded me that we had such a situation back in
> the early 7.x days.  I can see that I still occasionally made commits
> into 7.1 and 7.2 years after the last releases of those branches,
> which ended up being a complete waste of effort.  There was no policy
> guiding what to back-patch into what branches, partly because we
> didn't have a defined EOL policy then.  So I want to have a policy
> (and a pretty tight one) before I'll go back to doing that.
>
> Roughly speaking, I think the policy should be "no feature bug fixes,
> not even security fixes, for EOL'd branches; only fixes that are
> minimally necessary to make it build on newer platforms".  And
> I want to have a sunset provision even for that.  Fixing every branch
> forevermore doesn't scale.

Sure, but you can ameliorate that a lot by just saying it's something
people have the *option* to do, not something anybody is *expected* to
do. I agree it's best if we continue to discourage back-patching bug
fixes into supported branches, but I also think we don't need to be
too stringent about this. What I think we don't want is, for example,
somebody working at company X deciding to back-patch all the bug fixes
that customers of company X cares about into our back-branches, but
not the other ones. But on the other hand if somebody is trying to
benchmark or test compatibility an old branch and it keeps crashing
because of some bug, telling them that they're not allowed to fix that
bug because it's not a sufficiently-minimal change to a dead branch is
kind of ridiculous. In other words, if you try to police every change
anyone wants to make, e.g. "well I know that would help YOU build on a
newer platform but it doesn't seem like it meets the criteria of the
minimum necessary change to make it build on a newer platform," then
you might as well just give up now. Nobody cares about the older
branches enough to put work into fixing whatever's wrong and then
having to argue about whether that work ought to be thrown away
anyway.

> There's also the question of how we get to a working state in the
> first place -- as we found upthread, there's a fair-sized amount
> of work to do just to restore buildability right now, for anything
> that was EOL'd more than a year or two back.  I'm not volunteering
> for that, but somebody would have to to get things off the ground.

Right.

> Also, I concur with Andrew's point that we'd really have to have
> buildfarm support.  However, this might not be as bad as it seems.
> In principle we might just need to add resurrected branches back to
> the branches_to_build list.  Given my view of what the back-patching
> policy ought to be, a new build in an old branch might only be
> required a couple of times a year, which would not be an undue
> investment of buildfarm resources.  (Hmmm ... but disk space could
> become a problem, particularly on older machines with not so much
> disk.  Do we really need to maintain a separate checkout for each
> branch?  It seems like a fresh checkout from the repo would be
> little more expensive than the current copy-a-checkout process.)

I suppose it would be useful if we had the ability to do new runs only
when the source code has changed...

-- 
Robert Haas
EDB: http://www.enterprisedb.com