Re: State of support for back PG branches

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> I think there should be levels of support.

There already are, in that only fairly major bugs get backpatched to the
way-back releases. I think that's right --- the older a release is, the
more it means that people still using it value stability over the latest
fixes. The question at hand is when are we willing to pull the plug
completely and declare that even security holes and data-loss risks
won't get fixed.

> Although this will be tougher as versions such as 7.4 could easily be
> running in another 3 years
> as it is a reasonable stable version without any significant issue
> (meaning production issue bugs).

Yeah. The biggest reason we declared 7.1 unsupported is that it has the
unfixable transaction-ID-wraparound problem, and we wanted to encourage
people to stop using 7.1 and before ASAP. 7.2 has some pretty serious
unfixable problems too, such as the lack of error checking associated
with OPAQUE-using functions (ye olde "select cash_out(2)" crash).
7.3 is the oldest version that I think is actually supportable, in that
there are no known, unfixable security or data-loss risks.

So another way we might approach this is that it's time to kill 7.2
because we want to encourage people to get off it sooner not later, but
7.3 and later still have an indefinite support lifespan ahead of them.
In that mindset, we'd only pull the plug on a version when an
identifiable reason to kill it emerges. I'd still not commit to an
infinite lifespan --- but we might be willing to support solid versions
for as long as, say, five years.

Or, as you say, we could take the viewpoint that there are commercial
companies willing to take on the burden of supporting back releases, and
the development community ought not spend its limited resources on doing
that. I'm hesitant to push that idea very hard myself, because it would
look too much like I'm pushing the interests of my employer Red Hat
... but certainly there's a reasonable case to be made there.

regards, tom lane