Robert Haas wrote:
We had a discussion back in July about our maintenance policy and the
upshot of that discussion was that there were relatively few
objections to dropping support for 7.4 - I believe Andrew Dunstan was
the only one who spoke against it, and it wasn't clear how strenuous
his objections were - but there were objections even to setting an
end-of-life date for any subsequent release. However, we never really
took any action based on that conversation. Maybe it's time?
I don't object to EOLing 7.4, although I have a certain nostalgia for it
... it's the first release that contains anything of mine in it ;-)
What I want is a proper process for declaring an EOL, though. In
particular, we should announce it loudly and well in advance (by which I
mean several months). The PR team should swing into action with a press
release along the lines of "PostgreSQL release version n.n. will reach
the end of its maintenance life on yyyy-mm-dd. No patches of any kind
will be made after that date. Users of this version are advised to start
planning now to upgrade to a more modern version."
I think the objections to declaring a hard and fast release lifetime in
advance were well taken, though. And they aren't really relevant to a
discussion of whether it is now appropriate to EOL 7.4.
Part of the reason I suggest this is because it seems that not much
gets patched back that far any more. AFAICT, committers basically
stop back-patching at the point where it becomes an inconvenience, and
most of the time that happens before you get that far back. As a
result, while 7.4 is technically supported, it's not really all that
supported.
Tom just backpatched something to 7.4 the other day.
It's not a matter of convenience, but many things that get backpatched
relate to features introduced in relatively recent releases, not
surprisingly. e.g. see Peter's commit message from today, "Backpatched
back to 8.0, where this code was introduced."
Very occasionally things are seriously hard to backpatch. But that's the
exception, not the rule.
We are also very close to six years from the original release, if
that's a magic number for anyone.
Actually, I think it's a pretty good lifetime for a release. Many users
don't want to migrate as soon as a new version comes out, they want to
let it settle down. And they also don't want to have to go through the
pain of migrating more than once every few years - five would be a good
number here. (This has nothing to do with whether or not we have in
place upgrade. It's more to do with the effort involved in revalidating
a large application against a new release.) So allowing for those two
things, six years is an excellent lifetime. And 7.4 has been pretty darn
robust, it should be noted.
The fact that we have quite long release lifetimes and outstanding
release stability is a major plus for us. I have had users tell me over
and over that that's one of the reasons they use Postgres.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
