EOL for 7.4?

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

2009/11/3 Andrew Dunstan <andrew@dunslane.net>:

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."

Didn't we discuss EOLing based on <number of previous versions>? As in
if we now announced that 7.4 would EOL when we release 8.5?

(Though based on previous track record, that means it really should've
been EOLed when we released 8.4, I guess)

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.

Yeah, if one version has to stick around for a long time, 7.4 was a
good choice for it :-)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Andrew Dunstan <andrew@dunslane.net> writes:

Robert Haas wrote:

Part of the reason I suggest this is because it seems that not much
gets patched back that far any more.

Tom just backpatched something to 7.4 the other day.

A quick look in the cvs history shows 5 commits to 7.4 since the last
set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3.
A couple of these patches were Windows-specific and were made only back
to 8.2 because we desupported Windows in older branches awhile back.
So far as I can see, the others were all made as far back as applicable.
I think the lack of churn in 7.4 just means it's gotten pretty darn
stable.

I'm not averse to EOL'ing 7.4, but I don't think it's fair to claim that
we already stopped supporting it.

regards, tom lane

Tom Lane escribi�:

A quick look in the cvs history shows 5 commits to 7.4 since the last
set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3.
A couple of these patches were Windows-specific and were made only back
to 8.2 because we desupported Windows in older branches awhile back.
So far as I can see, the others were all made as far back as applicable.
I think the lack of churn in 7.4 just means it's gotten pretty darn
stable.

If it's all that stable, what's the point in EOLing it? The only extra
pain it causes is having to check whether each patch needs to be
backpatched to it or not.

(Maybe this means we can announce today that we're going to EOL it in a
distant future, say in a year.)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Magnus Hagander wrote:

2009/11/3 Andrew Dunstan <andrew@dunslane.net>:

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."

Didn't we discuss EOLing based on <number of previous versions>? As in
if we now announced that 7.4 would EOL when we release 8.5?

(Though based on previous track record, that means it really should've
been EOLed when we released 8.4, I guess)

Indeed I recall that at least once the plan was to EOL 7.4 with the
release of 8.4(or rather keeping a max of 5 active release branches) but
I guess we kinda forgot about that :)

Stefan

On Tue, 2009-11-03 at 13:01 -0300, Alvaro Herrera wrote:

Tom Lane escribió:

A quick look in the cvs history shows 5 commits to 7.4 since the last
set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3.
A couple of these patches were Windows-specific and were made only back
to 8.2 because we desupported Windows in older branches awhile back.
So far as I can see, the others were all made as far back as applicable.
I think the lack of churn in 7.4 just means it's gotten pretty darn
stable.

If it's all that stable, what's the point in EOLing it? The only extra
pain it causes is having to check whether each patch needs to be
backpatched to it or not.

Agreed

Unless there are unfixable data loss bugs in it, I say we keep it.

Many people still run it, so why make them move?

--
Simon Riggs www.2ndQuadrant.com

2009/11/3 Simon Riggs <simon@2ndquadrant.com>:

On Tue, 2009-11-03 at 13:01 -0300, Alvaro Herrera wrote:

Tom Lane escribió:

A quick look in the cvs history shows 5 commits to 7.4 since the last
set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3.
A couple of these patches were Windows-specific and were made only back
to 8.2 because we desupported Windows in older branches awhile back.
So far as I can see, the others were all made as far back as applicable.
I think the lack of churn in 7.4 just means it's gotten pretty darn
stable.

If it's all that stable, what's the point in EOLing it?  The only extra
pain it causes is having to check whether each patch needs to be
backpatched to it or not.

Agreed

Unless there are unfixable data loss bugs in it, I say we keep it.

There's a difference between doing it and promising it.

As long as we are supporting it, we *have* to backpatch critical
things, even if that is a lot of extra work. Normally it isn't, but
the case will come up.

Nothing prevents us from backpatching simple things, and still
releasing minors, for a non-supported version. It's just that we don't
promise to do it.

Many people still run it, so why make them move?

Many people still run 7.3... We made them move...

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Unless there are unfixable data loss bugs in it, I say we keep it.

Many people still run it, so why make them move?

There are non-trivial amounts of effort required to produce and test
packages for each branch we maintain. That affects all of the
packagers to varying degrees and should not be overlooked.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start

On Tue, 2009-11-03 at 16:37 +0000, Dave Page wrote:

On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Unless there are unfixable data loss bugs in it, I say we keep it.

Many people still run it, so why make them move?

There are non-trivial amounts of effort required to produce and test
packages for each branch we maintain. That affects all of the
packagers to varying degrees and should not be overlooked.

I see we've already removed it from the home page anyway.

People that are running older releases need to be able to find info
about our position with respect to earlier releases. Keeping the docs
available is important, since people may need to read up on how to dump
data so it can be upgraded.

We need a link to "older releases" with mention something like
7.4 Considered Stable, no tracking or fixing of new bugs
7.3 Considered Stable, no tracking or fixing of new bugs
7.2 Considered Unstable; upgrade immediately to avoid data loss

Personally, I would be more inclined to keep 7.4 as a supported version
and remove support for 8.0, possibly 8.1 also. There's no need to remove
them in chronological order - we should remove them based upon whether
its sensible to maintain them further. It also helps if we can say we
support software over long periods of time; that's very important for
embedded software.

--
Simon Riggs www.2ndQuadrant.com

2009/11/3 Simon Riggs <simon@2ndquadrant.com>:

On Tue, 2009-11-03 at 16:37 +0000, Dave Page wrote:

On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Unless there are unfixable data loss bugs in it, I say we keep it.

Many people still run it, so why make them move?

There are non-trivial amounts of effort required to produce and test
packages for each branch we maintain. That affects all of the
packagers to varying degrees and should not be overlooked.

I see we've already removed it from the home page anyway.

People that are running older releases need to be able to find info
about our position with respect to earlier releases. Keeping the docs
available is important, since people may need to read up on how to dump
data so it can be upgraded.

We need a link to "older releases" with mention something like
7.4     Considered Stable, no tracking or fixing of new bugs
7.3     Considered Stable, no tracking or fixing of new bugs
7.2     Considered Unstable; upgrade immediately to avoid data loss

Personally, I would be more inclined to keep 7.4 as a supported version
and remove support for 8.0, possibly 8.1 also. There's no need to remove
them in chronological order - we should remove them based upon whether
its sensible to maintain them further. It also helps if we can say we
support software over long periods of time; that's very important for
embedded software.

+1

Pavel

Simon Riggs <simon@2ndQuadrant.com> writes:

Personally, I would be more inclined to keep 7.4 as a supported version
and remove support for 8.0, possibly 8.1 also.

That would be basically useless from a maintenance-effort perspective
--- if you don't work back through the branches in a methodical way when
back-patching, you're liable to make mistakes; and in any case you have
to study each branch delta even if you don't bother to commit.

regards, tom lane

On Tue, 2009-11-03 at 16:37 +0000, Dave Page wrote:

On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Unless there are unfixable data loss bugs in it, I say we keep it.

Many people still run it, so why make them move?

There are non-trivial amounts of effort required to produce and test
packages for each branch we maintain. That affects all of the
packagers to varying degrees and should not be overlooked.

This presumes a single group of packagers that does all releases. We'd
be the only project that does that, AFAICS.

Seems strange to limit tasks to just the same few people all the time.
We could ask for volunteer maintainers for releases, rather than just
say "the X people that do all the work no longer wish to do it and so
we're not going to let anyone else either". No volunteers, no releases.
That is exactly how this current project got started in the first place
- picking up the maintenance responsibility on code that the original
authors no longer wished to maintain.

As in all things, any major changes with respect to packages should be
discussed publicly, with notice given of any changes. Anybody that feels
it is worth supporting could then come forward to do so.

I hope we can avoid a sarcastic "over to you then Simon" reply. I'm not
volunteering for it, but we should give others the opportunity to do so.
My belief is there is a substantial user community for 7.4, and for 7.3
also. There is no reason why we should act like a commercial company
when we're a volunteer organisation.

So suggestion: announce that 7.4 will be EOLd in 6 months unless
volunteers come forward to support further releases. At the same time,
announce what the EOL plans are for other releases, so people can begin
planning upgrades. In most stable production systems the planning cycle
can extend to years, rather than weeks or months.

--
Simon Riggs www.2ndQuadrant.com

On Tue, Nov 3, 2009 at 10:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Robert Haas wrote:

Part of the reason I suggest this is because it seems that not much
gets patched back that far any more.

Tom just backpatched something to 7.4 the other day.

A quick look in the cvs history shows 5 commits to 7.4 since the last
set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3.
A couple of these patches were Windows-specific and were made only back
to 8.2 because we desupported Windows in older branches awhile back.
So far as I can see, the others were all made as far back as applicable.
I think the lack of churn in 7.4 just means it's gotten pretty darn
stable.

I'm not averse to EOL'ing 7.4, but I don't think it's fair to claim that
we already stopped supporting it.

Well, that would be overstating my position. We haven't stopped
supporting it, but there's less and less stuff that applies that far
back. I think it's better to draw a line in the sand and say "we're
going to stop supporting this release on this date" rather than
letting it go on and on and then waking up and realizing "hmm, nothing
ever applies that far back any more, I guess we don't support it".

...Robert

On Tue, Nov 3, 2009 at 12:13 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

On Tue, 2009-11-03 at 16:37 +0000, Dave Page wrote:

On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Unless there are unfixable data loss bugs in it, I say we keep it.

Many people still run it, so why make them move?

There are non-trivial amounts of effort required to produce and test
packages for each branch we maintain. That affects all of the
packagers to varying degrees and should not be overlooked.

This presumes a single group of packagers that does all releases. We'd
be the only project that does that, AFAICS.

Seems strange to limit tasks to just the same few people all the time.
We could ask for volunteer maintainers for releases, rather than just
say "the X people that do all the work no longer wish to do it and so
we're not going to let anyone else either". No volunteers, no releases.
That is exactly how this current project got started in the first place
- picking up the maintenance responsibility on code that the original
authors no longer wished to maintain.

As in all things, any major changes with respect to packages should be
discussed publicly, with notice given of any changes. Anybody that feels
it is worth supporting could then come forward to do so.

I hope we can avoid a sarcastic "over to you then Simon" reply. I'm not
volunteering for it, but we should give others the opportunity to do so.
My belief is there is a substantial user community for 7.4, and for 7.3
also. There is no reason why we should act like a commercial company
when we're a volunteer organisation.

So suggestion: announce that 7.4 will be EOLd in 6 months unless
volunteers come forward to support further releases. At the same time,
announce what the EOL plans are for other releases, so people can begin
planning upgrades. In most stable production systems the planning cycle
can extend to years, rather than weeks or months.

But the effort is distributed across multiple people working at
different companies. There are many people involved in packaging
PostgreSQL and we may not even know who all of them are, though we
probably do know the major ones. Plus Peter updates translations,
Marc stamps releases, Tom and others backpatch bug fixes, etc. You're
not going to take all those little dribs and drabs of responsibility
and transfer them to one person, or even one group of people.

We certainly don't have to EOL 7.4. But neither can we maintain an
infinite collection of back-branches forever. So we just need to
decide whether it's time. If so, we pick a date and announce it. If
not, we go on as we are and come back around to this topic in another
six months. Personally, I think it would be reasonably to make the
announcement that 7.4 will be EOL when 8.5 is released, but YMMV,
BANI.

...Robert

Robert Haas wrote:

I'm not averse to EOL'ing 7.4, but I don't think it's fair to claim that
we already stopped supporting it.

Well, that would be overstating my position. We haven't stopped
supporting it, but there's less and less stuff that applies that far
back. I think it's better to draw a line in the sand and say "we're
going to stop supporting this release on this date" rather than
letting it go on and on and then waking up and realizing "hmm, nothing
ever applies that far back any more, I guess we don't support it".

I think you are mis-diagnosing the reason not everything gets
backpatched that far. It's not that we can't, it's that we don't always
need to.

cheers

andrew

On Tue, 2009-11-03 at 12:29 -0500, Robert Haas wrote:

You're
not going to take all those little dribs and drabs of responsibility
and transfer them to one person, or even one group of people.

With respect to all the people you just mentioned, I don't see any
reason why other people could not perform the duties you describe. Of
course, it might require a little effort, as we might expect of any
handover of responsibility.

Those last 3 words seem to be a big sticking point, so much so that
we're not even going to ask whether somebody else is willing to try. I
see no reason to act that way and certainly no benefit for our users.

--
Simon Riggs www.2ndQuadrant.com

Many people still run [7.4], so why make them move?

Many people still run 7.3... We made them move..

A nitpick. Nobody "made" anyone move.

PHP 4 was EOL some time ago but is still in widespread use. We still see
occasional postings regarding 7.3 and sometimes even earlier.

The software doesn't suddenly stop working when it hits EOL. It is just
an expectations-setting statement to end-users that the release is no
longer likely to receive attention from the core team.

Users are, of course, free to use/self-support the software as they see
fit. It's open-source, after all.

Cheers,
Steve
(who is in favor of 7.4 EOL despite one remaining 7.4 server in my
upgrade queue)

On Tue, Nov 3, 2009 at 5:23 PM, Robert Haas <robertmhaas@gmail.com> wrote:

Well, that would be overstating my position.  We haven't stopped
supporting it, but there's less and less stuff that applies that far
back.  I think it's better to draw a line in the sand and say "we're
going to stop supporting this release on this date" rather than
letting it go on and on and then waking up and realizing "hmm, nothing
ever applies that far back any more, I guess we don't support it".

If there are few or no patches that have to be back-patched then that
seems like an argument against EOLing it -- we can support it
basically for free!

Realistically we're going to EOL it as soon as the first major bug is
found that *doesn't* back patch readily. There's relatively low cost
to supporting it up until that bug is found, and apparently it hasn't
been found it.

The dangers I see are:

1) The committers waste time back patching minor bug fixes to a
release we would rather people not be using anyways.

2) Relatively few people are using it so perhaps the reason we haven't
found any major bugs recently is because nobody's pushing it hard any
more.

3) We're effectively making a promise we have no intention of
delivering on. We claim we "support" it but when we find that
hard-to-fix security problem or data corruption problem we'll suddenly
EOL it leave people hanging.

I think all of these are pretty minor problems in practice. The first
because the committers themselves don't seem to be concerned, the
second because these releases got pushed pretty hard for pretty long
already, and the third because as Steve Crawford mentioned EOLing
software doesn't instantly render it useless. It's not like we make
any real support commitments unless you actually contract one of our
employers anyways. And even if a bug isn't fixed you can usually
engineer your application to work around the problem anyways by, for
example, avoiding use of hash indexes or using password authentication
instead of SSL certs, or whatever.

--
greg

All,

So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd be in
favor of doing so in, say, February after an announcement this month.

The main reason I'm in favor of this is that we have a lot of users
using 7.4 out of inertia, and they need a message that 7.4 is "not
supported" to get them to upgrade. I can think of several here in SF
who have been "working on upgrade plans" for the past 3 years. An EOL
is what's needed to give them a kick in the pants.

The same goes for other OSS projects. There's quite a few random OSS
apps which were created on PG 7.4 and have never offered their users an
upgrade path (Gnuworld comes to mind). They need an EOL announcement to
get them motivated to upgrade.

This isn't just a matter of supporting these users; it's a matter of
what new developers think of Postgres. Programmers judge PG based on
the version they first encounter, and they often don't check to see if
later versions exist or what features they have.

We'd want to do a full publicity around this, including a "how do I
upgrade" page and an "what does EOL mean for an OSS project" page. If
this goes well, we could EOL 8.0 after 8.5 comes out, and thus decrease
our maintenance burden.

This will also create some favorable spin around how long we do keep
patching stuff ... how many other OSS projects batch-fix 5 years?

Also, as Greg points out, 7.4 is just waiting for some exploit which is
horribly hard to backpatch for us to desupport it on short notice, and
that is NOT a service to our users.

--Josh Berkus