On 02.12.21 18:30, Tom Lane wrote:
This assumes a yearly major release cadence.
If the point is to not have to count dates carefully, why does the cadence
matter?
If we were to change the release cadence, then it would be appropriate
to review this policy.
I can get behind something roughly like this, but I wonder if it wouldn't
be better to formulate the policy in a reactive way, i.e. when X happens
we'll do Y. If we don't plan to proactively remove some code every year,
then it seems like the policy really is more like "when something breaks,
then we'll make an attempt to keep it working if the release is less than
ten majors back; otherwise we'll declare that release no longer
buildable."
This sounds like it would give license to accidentally break support for
old releases in the code and only fix them if someone complains. That's
not really what I would be aiming for.
I agree with the idea of being conservative about what outside
dependencies we will worry about for "buildable" old versions.
(Your nearby message about Python breakage is a good example of
why we must limit that.) But I wonder about, say, libxml or libicu,
or even if we can afford to drop all the non-plpgsql PLs. An
example of why that seems worrisome is that it's not clear we'd
have any meaningful coverage of transforms in pg_dump with no PLs.
I don't have any immediate proposal here, but it seems like an area
that needs some thought and specific policy.
Yeah, I think questions like this will currently quickly lead to dead
ends. We are talking 5 years this, 10 years that here. Everybody else
(apart from RHEL) is talking at best in the range 3-5 years. We will
have to figure this out as we go.
