Re: EOL for 7.4?

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?

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.

We are also very close to six years from the original release, if
that's a magic number for anyone.

...Robert

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(at)dunslane(dot)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(at)dunslane(dot)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(at)dunslane(dot)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(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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           www.2ndQuadrant.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Simon Riggs <simon(at)2ndQuadrant(dot)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(at)2ndquadrant(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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(at)gmail(dot)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

On Tue, 2009-11-03 at 10:04 -0800, Steve Crawford wrote:

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

I've heard that a lot recently: "It's open source, after all".

Is this project not open source any more?

Surely this project should be encouraging people within the project to
take on new tasks. I don't think anybody should be forced to do anything
they don't want to do. So if particular developers want to avoid
patching certain releases, I respect that. But I don't see why *this*
project cannot allow others to take on the tasks those developers choose
not to perform. Why are we forcing people into a position where they
have to set up their own independent project, what others would call a
fork, in order to support software? Why are we not even willing to ask
whether someone is willing? It all seems very strange to me.

--
Simon Riggs www.2ndQuadrant.com

Simon,

> Why are we not even willing to ask
> whether someone is willing? It all seems very strange to me.

Mostly because, I think, nobody can picture how this would be structured
or where the people would come from. Surely a "7.4 maintainer" would do
only one platform? Or only source? Can we call 7.4 a "maintained"
version if it's only patched for Debian?

Also, given the other needs we have for technical skills, this would
depend on finding people who were good enough to put out stable packages
for 7.4, but wasn't interested in contributing to the project in any
other way. If these people are available for other tasks, we'd *far*
rather have them testing 8.5, reviewing code, updating drivers, writing
docs, making tools, etc.

So I don't think that anyone is opposed to your proposal, they just
don't (or at least I don't) see a practical way to pursue it.

--Josh Berkus

On Tue, Nov 3, 2009 at 1:32 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> 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.

That is along the line of my concerns as well. Based on a quick look
through my pgsql-bugs email, it seems that we don't get many bug
reports for 7.4 or even 8.0. Mostly, the fixes that are being
back-patched to 7.4 are problems that were found on (much) later
releases and happened to go all the way back. We are supporting 7.4
to the extent that the 7.4 code overlaps with the 8.4 code (soon, the
8.5 code), but are we supporting the code in 7.4 that IS NO LONGER IN
HEAD? I suspect we are to a point, but not really - and I don't
believe that the removed code is bug-free any more than I believe that
HEAD is bug-free.

I don't really object to supporting 7.4 on the grounds that it is a
lot of work. It obviously isn't, or the committers would have stopped
doing it before now. I'm more concerned about the perception that the
code is more supported than it really is. If we don't want to
actually EOL 7.4, then perhaps we should decide for which releases
we'd be willing to fix a major bug that affected only that release and
for which we would not, and then publish that information so that
users can make an informed decision.

...Robert

On Nov 3, 2009, at 10:32 AM, Josh Berkus wrote:

> 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

+1

And, frankly, I think that we still need a published deprecation
policy -- or at least a set of guidelines. That was my point in
starting this discussion back in July.

Best,

David

On Tue, 2009-11-03 at 10:49 -0800, Josh Berkus wrote:

> > Why are we not even willing to ask
> > whether someone is willing? It all seems very strange to me.
>
> Mostly because, I think, nobody can picture how this would be structured
> or where the people would come from. Surely a "7.4 maintainer" would do
> only one platform? Or only source? Can we call 7.4 a "maintained"
> version if it's only patched for Debian?

Only if you turn off the buildfarm for them.

> Also, given the other needs we have for technical skills, this would
> depend on finding people who were good enough to put out stable packages
> for 7.4, but wasn't interested in contributing to the project in any
> other way. If these people are available for other tasks, we'd *far*
> rather have them testing 8.5, reviewing code, updating drivers, writing
> docs, making tools, etc.

These are currently hypothetical problems. Some people may care, if so,
they can work out the problems. We might find some people that are
willing to take on responsibility and grow into the role. We will
probably end up with more new developers, not less.

> So I don't think that anyone is opposed to your proposal, they just
> don't (or at least I don't) see a practical way to pursue it.

Why not ask for volunteers and let them work it out?

Perhaps there are people not willing to receive the "kick in the pants"
you advocate elsewhere. Ask people, let them decide.

--
Simon Riggs www.2ndQuadrant.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

The other Greg wrote:

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

I hope this is not the case, for sane definitions of "readily". We have
an implicit promise to support 7.4 until we state that we've stopped
doing so. Stopping because a patch is hard seems a real crappy excuse.
For the record, I'd like to see a year's notice. How about Dec. 1, 2010?
February is completely not reasonable. Companies need a lot more time to
make plans, get approval, test, etc.

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

Or maybe it's a relatively stable branch that people are happy with. As
far as "few people", where do you get that idea, except anecdotally? I
can assure I know of a number of companies that are using it (and some
using 7.3, but shame on them). These companies do not advertise their
usage of Postgres, and their use of the database stays the same so no
bugs are revealed, but they are out there.

Josh writes:
> 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.

That will get some, but not others. What really makes people upgrade
their database is when their database driver stops working against it. :)

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200911031423
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkrwg4cACgkQvJuQZxSWSsipyQCfb3ZMEnscjrQzj02j/6eGFWdj
3csAoIGwgvA5Y/GfBV47FddjvpZfUGEg
=RQOY
-----END PGP SIGNATURE-----

On Tue, Nov 3, 2009 at 2:24 PM, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote:
> That will get some, but not others. What really makes people upgrade
> their database is when their database driver stops working against it. :)

ROFL.

...Robert

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> 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.

It's not "handover of responsibility" that's the issue, it's that
dividing up existing responsibility entails more communication and
synchronization overhead. If we have a separate set of people
back-patching and releasing old branches, then every time we make a bug
fix, we have to explain the patch to them; every time we have a release,
we have to get their concurrence on release schedule. And we have to
track whether patches that should be back-patched have been. The added
overhead of all that would easily exceed the time savings of pushing off
the responsibility, IMO.

(As an example, it's already been determined among core and -packagers
that there will be no 8.4.2 during November, because we can't get
everyone's time to make a release this month. Putting even more
people in the loop does NOT make that better. And they can't be
out of the loop --- for instance, if it's a security update, 7.4.x
had better come out at the same time as the other branches.)

regards, tom lane

Josh Berkus wrote:
> ...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'm not entirely sure that inertia is the culprit. From what I've seen,
since 7.4 is a good, stable release, checking/fixing everything required
for an upgrade (casting, time-calculation changes, administrative
procedures, perhaps switching from C to UTF8, client-deployment planning
and so on) combined with risks of the unknown and 24x7 availability
requirements makes the required expenditure a tough sell - especially in
a "lean and mean" economy. I suspect 7.4 will remain in somewhat
widespread use for quite some time after EOL.

EOL _does_, however, give IT some powerful ammo to use to in persuading
management to devote the required resources to an upgrade.

Cheers,
Steve

On Tue, Nov 03, 2009 at 10:32:17AM -0800, Josh Berkus wrote:
> 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.

+1

-dg

--
David Gould daveg(at)sonic(dot)net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.

On Tue, 2009-11-03 at 15:01 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > 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.
>
> It's not "handover of responsibility" that's the issue, it's that
> dividing up existing responsibility entails more communication and
> synchronization overhead. If we have a separate set of people
> back-patching and releasing old branches, then every time we make a bug
> fix, we have to explain the patch to them; every time we have a release,
> we have to get their concurrence on release schedule. And we have to
> track whether patches that should be back-patched have been. The added
> overhead of all that would easily exceed the time savings of pushing off
> the responsibility, IMO.

This is essentially the "delegation isn't worth it" argument. Which
doesn't really wash because there clearly is delegation already. There
was also a time when those people started and needed to work things
out.

I'd hold my hand up and say I love to do things myself rather than
delegate, but I won't be arguing that makes sense ahead of knowing: if
there is a delegatee at all, how they would want to operate, who they
are and what they know.

> (As an example, it's already been determined among core and -packagers
> that there will be no 8.4.2 during November, because we can't get
> everyone's time to make a release this month. Putting even more
> people in the loop does NOT make that better. And they can't be
> out of the loop --- for instance, if it's a security update, 7.4.x
> had better come out at the same time as the other branches.)

You're also presupposing that we would need to synchronize things in the
way you say. It seems strange to be in a position where we either
release everything in lock-step, or just jettison it completely. So we
can have everything or nothing.

All I'm saying is that some people may be willing to live with something
rather than nothing. I might be wrong and nobody gives a damn, but as a
project I feel we should at least check to see whether people care
enough to act. Or maybe do it for the experience. Who knows without
asking?

--
Simon Riggs www.2ndQuadrant.com

On Tue, Nov 3, 2009 at 7:24 PM, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote:
>> 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.
>
> I hope this is not the case, for sane definitions of "readily". We have
> an implicit promise to support 7.4 until we state that we've stopped
> doing so. Stopping because a patch is hard seems a real crappy excuse.
> For the record, I'd like to see a year's notice. How about Dec. 1, 2010?
> February is completely not reasonable. Companies need a lot more time to
> make plans, get approval, test, etc.

It seems like a fine excuse to me. I certainly don't feel i have any
authority to tell Tom or Alvarro what to work on in their spare time.
If you feel the urge to do it if Tom thinks it's too much work to be
worthwhile then, well, more power to you, thanks.

These companies are free to keep using the software with the known
problems or pay someone to support it and do the pointless work fixing
bugs in five-year-old versions if they want.

It looks to me like our "support policy" and past success at back
patching has engendered a false sense of security for users. *All* our
support is "best-effort" and what I described is effectively our
policy for all back branches. The only question is which branches, in
our best judgement, we think we're likely to run into such a problem.
It's not likely for 8.3 currently because we know there aren't very
many major changes in 8.4 that fixed potential major design bugs. It's
certainly likely for 7.4 at this point and really 8.0 and 8.1 wouldn't
surprise me either.

That doesn't mean we have to stop back patching to 7.4, 8.0, and 8.1
today. But if we think it's likely we'll run into some major bug which
requires a redesign to fix then we should perhaps make some statement
to that effect, call these back branches EOL today, and just release
back branches on a best effort basis until that occurs.

--
greg

Is a somewhat related question "how long are the various commercial
support organizations committed to supporting 7.4"?

I guess support companies might support their client's systems
for longer or shorter times than the community patches the old
versions. No doubt it's easier for them if the community
does the backpatching. But if any of those companies has
a lot of 7.4 clients, they might be tempted to deal with
backpatches for their clients even after the community stops.

On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:

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

I know several customers who decided to move from 7.3 only after the
EOL was announced. If 7.3 would not has see an EOL, they would never
ever have moved to a newer version.

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

+1

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project

Andreas 'ads' Scherbaum wrote:
> On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
>
>
>> 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.
>>
>
> I know several customers who decided to move from 7.3 only after the
> EOL was announced. If 7.3 would not has see an EOL, they would never
> ever have moved to a newer version.
>

Nobody that I have seen is arguing against EOLing 7.4.

>
>
>> 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.
>>
>
> +1
>

The only burden of significance I have seen actually mentioned, as
opposed to supposed, is from Dave Page.

What I and others have been arguing is necessary to do EOL right is a
serious amount of notice, by way of press releases etc. We can't expect
users to keep polling our web site to see if there's an EOL. That means
we need to prepare for an EOL months or a year in advance, ISTM.

cheers

andrew

--On 12. November 2009 15:23:06 -0500 Andrew Dunstan <andrew(at)dunslane(dot)net>
wrote:

> What I and others have been arguing is necessary to do EOL right is a
> serious amount of notice, by way of press releases etc. We can't expect
> users to keep polling our web site to see if there's an EOL. That means
> we need to prepare for an EOL months or a year in advance, ISTM.

I think that's the key argument here. We have several customers, which need
a very careful and time consuming evaluation before they can go into
production with a new platform, which is quite time consuming and needs
significant preparation for them. Announcing an EOL early in time would
give them the required time before the version used disappears.

--
Thanks

Bernd

> I think that's the key argument here. We have several customers, which
> need a very careful and time consuming evaluation before they can go
> into production with a new platform, which is quite time consuming and
> needs significant preparation for them. Announcing an EOL early in time
> would give them the required time before the version used disappears.

So, should we announce it for June?

--Josh Berkus

On Thu, 12 Nov 2009 15:23:06 -0500 Andrew Dunstan wrote:

> Andreas 'ads' Scherbaum wrote:
> > On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
> >
> >
> >> 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.
> >>
> >
> > I know several customers who decided to move from 7.3 only after the
> > EOL was announced. If 7.3 would not has see an EOL, they would never
> > ever have moved to a newer version.
> >
>
>
> Nobody that I have seen is arguing against EOLing 7.4.

True. But as Josh pointed out: some people/projects/companies need
more "motivation" to actually consider an upgrade at all.

> What I and others have been arguing is necessary to do EOL right is a
> serious amount of notice, by way of press releases etc. We can't expect
> users to keep polling our web site to see if there's an EOL. That means
> we need to prepare for an EOL months or a year in advance, ISTM.

Months. The software will not stop working once we announced the EOL.
And yes, i'm +1 for having a rule for EOL, like "5 versions are
supported".

Bye

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project

On Thu, 2009-11-12 at 23:09 +0100, Andreas 'ads' Scherbaum wrote:
> On Thu, 12 Nov 2009 15:23:06 -0500 Andrew Dunstan wrote:
>
> > Andreas 'ads' Scherbaum wrote:
> > > On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote:
> > >
> > >
> > >> 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.
> > >>
> > >
> > > I know several customers who decided to move from 7.3 only after the
> > > EOL was announced. If 7.3 would not has see an EOL, they would never
> > > ever have moved to a newer version.
> > >
> >
> >
> > Nobody that I have seen is arguing against EOLing 7.4.
>
> True. But as Josh pointed out: some people/projects/companies need
> more "motivation" to actually consider an upgrade at all.

We have discussed in the past EOLing 7.4 I thought at the end of this
year. IMO 7.4 and 8.0 both need to be EOL. Can we just set a date and
call it good? March 31st sounds good.

Let's write up a quick announcement, add the letters EOL to the download
pages and call it good.

Joshua D. Drake

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
If the world pushes look it in the eye and GRR. Then push back harder. - Salamander

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

>> needs significant preparation for them. Announcing an EOL early in time
>> would give them the required time before the version used disappears.
>
> So, should we announce it for June?

No, it should be longer. June is practically around the corner
as far as business planning is concerned. Make it a year. Since it's
mid November, why not just say 2011?

> And yes, i'm +1 for having a rule for EOL, like "5 versions are
> supported".

If we released on a consistent schedule, this *might* be possible.
But we don't, so we can't say something like this.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200911121815
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkr8lykACgkQvJuQZxSWSsi6xACdHU7xKgsfG+/zE2StXp97mdjC
XGoAn3LvIjzh1RKmD9K0Zyrg9W3LuHxt
=jCVo
-----END PGP SIGNATURE-----

On Thu, 2009-11-12 at 23:16 +0000, Greg Sabino Mullane wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
> >> needs significant preparation for them. Announcing an EOL early in time
> >> would give them the required time before the version used disappears.
> >
> > So, should we announce it for June?
>
> No, it should be longer. June is practically around the corner
> as far as business planning is concerned. Make it a year. Since it's
> mid November, why not just say 2011?

If a business wants support they can buy it. There is no reason for this
community to continue supporting it.

>
> > And yes, i'm +1 for having a rule for EOL, like "5 versions are
> > supported".
>
> If we released on a consistent schedule, this *might* be possible.
> But we don't, so we can't say something like this.
>

We can say 5 "years" from release though.

Joshua D. Drake

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
If the world pushes look it in the eye and GRR. Then push back harder. - Salamander

On Thu, Nov 12, 2009 at 11:16 PM, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote:
>> And yes, i'm +1 for having a rule for EOL, like "5 versions are
>> supported".
>
> If we released on a consistent schedule, this *might* be possible.
> But we don't, so we can't say something like this.

We've already done this. I think we said three years but I'm too lazy
to go search right now. It's as meaningless now as it was then. The
reality is we back branch as far back as is convenient and stop when
we run into a major problem that isn't fixable in old versions. 7.4
and even 8.0 are already "EOL" in the sense that they're past your
arbitrary cutoff and there's no guarantee that we'll keep releasing
fixes but there's no particular reason to stop yet.

Really I think you guys are on the wrong track trying to map Postgres
releases to commercial support terms. None of the Postgres releases
are "supported" in the sense that there's no warranty and no promises,
it's all best effort. If you want a promise of anything then pay
someone for that service.

As with any open source software if you're running 7-year-old versions
of the software you can't seriously expect the developers to take any
interest in bugs you discover which don't affect current releases.
Other projects don't release back branches at all. The most the
developers are likely to do if your bugs require serious engineering
is declare that the version you're using is too old.

--
greg

On Fri, Nov 13, 2009 at 02:22:01AM +0000, Greg Stark wrote:
>
> Really I think you guys are on the wrong track trying to map Postgres
> releases to commercial support terms. None of the Postgres releases
> are "supported" in the sense that there's no warranty and no promises,
> it's all best effort. If you want a promise of anything then pay
> someone for that service.
>
> As with any open source software if you're running 7-year-old versions
> of the software you can't seriously expect the developers to take any
> interest in bugs you discover which don't affect current releases.
> Other projects don't release back branches at all. The most the
> developers are likely to do if your bugs require serious engineering
> is declare that the version you're using is too old.

Claiming to support versions that are "too old" is giving users a false
sense of comfort. Encouraging users to use these versions is actually
harming them as when this happens they will be stuck with either living
with the bug or doing an immediate unplanned upgrade.

I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected
to ship, or to comfort those who never use .0 versions when 8.5.1 ships.

-dg

--
David Gould daveg(at)sonic(dot)net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.

daveg wrote:
> On Fri, Nov 13, 2009 at 02:22:01AM +0000, Greg Stark wrote:
> >
> > Really I think you guys are on the wrong track trying to map Postgres
> > releases to commercial support terms. None of the Postgres releases
> > are "supported" in the sense that there's no warranty and no promises,
> > it's all best effort. If you want a promise of anything then pay
> > someone for that service.
> >
> > As with any open source software if you're running 7-year-old versions
> > of the software you can't seriously expect the developers to take any
> > interest in bugs you discover which don't affect current releases.
> > Other projects don't release back branches at all. The most the
> > developers are likely to do if your bugs require serious engineering
> > is declare that the version you're using is too old.
>
> Claiming to support versions that are "too old" is giving users a false
> sense of comfort. Encouraging users to use these versions is actually
> harming them as when this happens they will be stuck with either living
> with the bug or doing an immediate unplanned upgrade.
>
> I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected
> to ship, or to comfort those who never use .0 versions when 8.5.1 ships.

I question whether it makes sense to EOL a version just to encourage
people to upgrade --- that logic really seems beyond our scope. It
might be practical to do it, but I see it taking us in a direction that
we might want to avoid.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Fri, Nov 13, 2009 at 2:35 AM, daveg <daveg(at)sonic(dot)net> wrote:
> I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected
> to ship, or to comfort those who never use .0 versions when 8.5.1 ships.

What would this mean? How would it be different than the status quo?

--
greg

On Thu, Nov 12, 2009 at 9:40 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> daveg wrote:
>> On Fri, Nov 13, 2009 at 02:22:01AM +0000, Greg Stark wrote:
>> >
>> > Really I think you guys are on the wrong track trying to map Postgres
>> > releases to commercial support terms. None of the Postgres releases
>> > are "supported" in the sense that there's no warranty and no promises,
>> > it's all best effort. If you want a promise of anything then pay
>> > someone for that service.
>> >
>> > As with any open source software if you're running 7-year-old versions
>> > of the software you can't seriously expect the developers to take any
>> > interest in bugs you discover which don't affect current releases.
>> > Other projects don't release back branches at all. The most the
>> > developers are likely to do if your bugs require serious engineering
>> > is declare that the version you're using is too old.
>>
>> Claiming to support versions that are "too old" is giving users a false
>> sense of comfort. Encouraging users to use these versions is actually
>> harming them as when this happens they will be stuck with either living
>> with the bug or doing an immediate unplanned upgrade.
>>
>> I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected
>> to ship, or to comfort those who never use .0 versions when 8.5.1 ships.
>
> I question whether it makes sense to EOL a version just to encourage
> people to upgrade --- that logic really seems beyond our scope.  It
> might be practical to do it, but I see it taking us in a direction that
> we might want to avoid.

I don't agree with "because we want to force people to upgrade", but I
do agree with Dave Gould's point about giving a false sense of comfort
(I made this same point upthread somewhere, I think).

...Robert

On Fri, Nov 13, 2009 at 02:47:56AM +0000, Greg Stark wrote:
> On Fri, Nov 13, 2009 at 2:35 AM, daveg <daveg(at)sonic(dot)net> wrote:
> > I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected
> > to ship, or to comfort those who never use .0 versions when 8.5.1 ships.
>
> What would this mean? How would it be different than the status quo?

I suppose it would mean posting periodic prominent notices, moving the sources
to the OLD directory, that sort of thing. I thought that was the topic of this
thread?

-dg

--
David Gould daveg(at)sonic(dot)net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

I wrote:

> No, it should be longer. June is practically around the corner
> as far as business planning is concerned. Make it a year. Since it's
> mid November, why not just say 2011?

This thread never got resolved. I think we can all agree that EOL
for 7.4 is a "when", not an "if"? Can we get -core to take a stance
here and pick a date? I like the clean smooth lines of January 2011,
and thus saying that 2010 is the last year in which we'll backpatch
things to the 7.4 branch. But I'll stick to whatever core thinks is
best. Just let the advocacy team know so we can start work on it.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation
PGP Key: 0x14964AC8 200912011122
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAksVQtgACgkQvJuQZxSWSsj26ACgr/QRKytEc9dWYar0gY6HJZ0C
YYsAni96hrCF0AmBIjY/Fg5vHS+LauKT
=ELLh
-----END PGP SIGNATURE-----

"Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
> This thread never got resolved. I think we can all agree that EOL
> for 7.4 is a "when", not an "if"? Can we get -core to take a stance
> here and pick a date? I like the clean smooth lines of January 2011,
> and thus saying that 2010 is the last year in which we'll backpatch
> things to the 7.4 branch. But I'll stick to whatever core thinks is
> best. Just let the advocacy team know so we can start work on it.

If we're going to set the date that far off, I'd be inclined to EOL
8.0 at the same time. It'll be six years old by then. You could
make a good argument for nuking 8.1 at the same time --- it'll turn
five in November 2010.

Personally I'll still be on the hook for maintaining 8.1 in RHEL5
so I'd be just as happy to keep it alive a bit longer, but if the
community doesn't want to deal with it that makes perfect sense.
I have no personal commitment to 8.0 at all because Red Hat never
shipped that in a RHEL release ...

regards, tom lane

On Tue, Dec 1, 2009 at 4:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
>> This thread never got resolved. I think we can all agree that EOL
>> for 7.4 is a "when", not an "if"? Can we get -core to take a stance
>> here and pick a date? I like the clean smooth lines of January 2011,
>> and thus saying that 2010 is the last year in which we'll backpatch
>> things to the 7.4 branch. But I'll stick to whatever core thinks is
>> best. Just let the advocacy team know so we can start work on it.
>
> If we're going to set the date that far off, I'd be inclined to EOL
> 8.0 at the same time.  It'll be six years old by then.  You could
> make a good argument for nuking 8.1 at the same time --- it'll turn
> five in November 2010.
>
> Personally I'll still be on the hook for maintaining 8.1 in RHEL5
> so I'd be just as happy to keep it alive a bit longer, but if the
> community doesn't want to deal with it that makes perfect sense.
> I have no personal commitment to 8.0 at all because Red Hat never
> shipped that in a RHEL release ...

Presumably you'll be on the hook until 2014 for 8.1 security patches
for RHEL 5 (looking at
http://www.redhat.com/security/updates/errata/)? I can't see the
community wanting to support it for that long, so I'd suggest we can
(respectfully) ignore your commitments in that regard.

I'm for EOLing *at least* 7.4 and 8.0 by January 2011, and I'm
certainly not going to argue against doing the same for 8.1. Frankly,
I think we could do 7.4 and maybe 8.0 six months earlier.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Tue, 1 Dec 2009, Tom Lane wrote:

> "Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
>> This thread never got resolved. I think we can all agree that EOL
>> for 7.4 is a "when", not an "if"? Can we get -core to take a stance
>> here and pick a date? I like the clean smooth lines of January 2011,
>> and thus saying that 2010 is the last year in which we'll backpatch
>> things to the 7.4 branch. But I'll stick to whatever core thinks is
>> best. Just let the advocacy team know so we can start work on it.
>
> If we're going to set the date that far off, I'd be inclined to EOL
> 8.0 at the same time. It'll be six years old by then. You could
> make a good argument for nuking 8.1 at the same time --- it'll turn
> five in November 2010.
>
> Personally I'll still be on the hook for maintaining 8.1 in RHEL5
> so I'd be just as happy to keep it alive a bit longer, but if the
> community doesn't want to deal with it that makes perfect sense.
> I have no personal commitment to 8.0 at all because Red Hat never
> shipped that in a RHEL release ...

Just curious, but since you do all the back patching as it is, and
building the source tarballs is simple enough ...

What are RedHats "EOL" dates for the various releases?

Doesn't mean that packagers have to make new packages ... I personally
think new packages shouldn't be made for anything older then *maybe* 3
releases (8.2, 8.3 and 8.4), but even that I think tends to be a bit
excessive ... but doing source tar balls is easy enough ...

----
Marc G. Fournier Hub.Org Hosting Solutions S.A.
scrappy(at)hub(dot)org http://www.hub.org

Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy(at)hub(dot)org

"Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> What are RedHats "EOL" dates for the various releases?

Dave already mentioned a public page for that:
http://www.redhat.com/security/updates/errata/

Based on track record so far, Red Hat isn't going to care about anything
but high-priority security issues towards the end of the life cycle,
but theoretically I'm on the hook till 2014 for 8.1.x.

regards, tom lane

is there a reason why we can't follow a similar 4+3 life cycle?
packagers r produced for the first 4y after .0 release and only source
updates for year 5 thru 7?

if we could advertise such on the web, there would be no question as
to when bug reports are accepted (n+4y) and when only security ... and
after y7, it's just not supported at all ...

that would kill packager requirements on 8.0, 8.1 (as of last month)
and totally kill 7.4 as of nov '10

Sent from my iPhone

On 2009-12-01, at 14:33, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
>> What are RedHats "EOL" dates for the various releases?
>
> Dave already mentioned a public page for that:
> http://www.redhat.com/security/updates/errata/
>
> Based on track record so far, Red Hat isn't going to care about
> anything
> but high-priority security issues towards the end of the life cycle,
> but theoretically I'm on the hook till 2014 for 8.1.x.
>
> regards, tom lane

Scrappy wrote:
> is there a reason why we can't follow a similar 4+3 life cycle?
> packagers r produced for the first 4y after .0 release and only source
> updates for year 5 thru 7?
>
> if we could advertise such on the web, there would be no question as
> to when bug reports are accepted (n+4y) and when only security ... and
> after y7, it's just not supported at all ...
>
> that would kill packager requirements on 8.0, 8.1 (as of last month)
> and totally kill 7.4 as of nov '10
>
>

What packagers produce is surely up to them. If RedHat or Devrim or Dave
want to produce a package that's their prerogative.

And IMNSHO 4 years is too short a period for non-security bugs. We have
seen odd behaviour issues past those dates.

The time between these periodic debates seems to be getting shorter and
shorter.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> The time between these periodic debates seems to be getting shorter and
> shorter.

No, this is just a continuation of the unresolved thread from a month or
so ago.

regards, tom lane

Tom Lane wrote:
> Personally I'll still be on the hook for maintaining 8.1 in RHEL5
> so I'd be just as happy to keep it alive a bit longer, but if the
> community doesn't want to deal with it that makes perfect sense.
>
Some people consider the extended support and easy upgrades of the RHEL5
versions valuable enough that they have a strong preference to use the
version of PostgreSQL that ships with it. Right now, when such people
ask me about using 8.1 in that context, I tell them while it would be
better if they ran something more recent, the performance of that
version is reasonable and the bugs they might run into aren't that
serious. This is not the case at all for either 7.4 or 8.0, which have
been completely indefensible as versions to consider deploying for quite
some time already.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

Greg Smith <greg(at)2ndquadrant(dot)com> writes:
> Some people consider the extended support and easy upgrades of the RHEL5
> versions valuable enough that they have a strong preference to use the
> version of PostgreSQL that ships with it. Right now, when such people
> ask me about using 8.1 in that context, I tell them while it would be
> better if they ran something more recent, the performance of that
> version is reasonable and the bugs they might run into aren't that
> serious. This is not the case at all for either 7.4 or 8.0, which have
> been completely indefensible as versions to consider deploying for quite
> some time already.

Well, actually, if it's just "what will RH support", I just today got
launch commit on this:
https://bugzilla.redhat.com/show_bug.cgi?id=489479
which might change things a bit. PG 8.1 will be *in* RHEL5 until 2014,
but whether many people will still be using it is another question.

regards, tom lane

Tom Lane wrote:
> Greg Smith <greg(at)2ndquadrant(dot)com> writes:
>
>> Some people consider the extended support and easy upgrades of the RHEL5
>> versions valuable enough that they have a strong preference to use the
>> version of PostgreSQL that ships with it. Right now, when such people
>> ask me about using 8.1 in that context, I tell them while it would be
>> better if they ran something more recent, the performance of that
>> version is reasonable and the bugs they might run into aren't that
>> serious. This is not the case at all for either 7.4 or 8.0, which have
>> been completely indefensible as versions to consider deploying for quite
>> some time already.
>>
>
> Well, actually, if it's just "what will RH support", I just today got
> launch commit on this:
> https://bugzilla.redhat.com/show_bug.cgi?id=489479
> which might change things a bit. PG 8.1 will be *in* RHEL5 until 2014,
> but whether many people will still be using it is another question.
>
>
>

Having 8.4 available and supported in RHEL5 will be nice. Maybe it was
spurred by the talk I gave on 8.4 a couple of weeks ago at RH HQ? (j/k).
But the issue for me is not what vendors support but how often we ask
someone to upgrade if they want to stay on a community supported base.
As I remarked before, other things being equal, I think five years is a
reasonable interval, and given that many users don't upgrade right on a
.0 release, I think a release lifetime of about six years is therefore
about right as a target.

cheers

andrew

Tom Lane wrote:
> Well, actually, if it's just "what will RH support", I just today got
> launch commit on this...
>
What I was trying to suggest was that right now, there are situations
where a new deployment on 8.1 is still completely reasonable and
possible to justify in the Enterprise Linux space, whereas I don't know
of any situation where 7.4/8.0 can be similarly defended as a good
idea. That makes supporting 8.1 quite a bit more valuable to the
community than the earlier releases IMHO.

Moving forward, I was hoping that we all get RHEL6 as a deployment
option in the not so distant future for a platform that integrates 8.4
from day one; I didn't think that deploying RHEL5 was going to be the
only choice for too much longer.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

Greg Smith <greg(at)2ndquadrant(dot)com> writes:
> What I was trying to suggest was that right now, there are situations
> where a new deployment on 8.1 is still completely reasonable and
> possible to justify in the Enterprise Linux space, whereas I don't know
> of any situation where 7.4/8.0 can be similarly defended as a good
> idea.

Okay, but how much of the argument for that hinges on it being the only
thing Red Hat will support on RHEL5?

> Moving forward, I was hoping that we all get RHEL6 as a deployment
> option in the not so distant future for a platform that integrates 8.4
> from day one; I didn't think that deploying RHEL5 was going to be the
> only choice for too much longer.

I don't believe I'm allowed to say anything about RHEL6 release
schedules. However, if you are paying attention to what has shipped in
recent Fedora releases, it's not hard to figure out that it will have
PG >= 8.4.

regards, tom lane

On Tue, 2009-12-01 at 17:14 -0500, Tom Lane wrote:
> However, if you are paying attention to what has shipped in
> recent Fedora releases, it's not hard to figure out that it will have
> PG >= 8.4.

I thought RHEL 6 would ship with 8.3. It will be perfect if it skips
8.3.
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

Tom Lane wrote:
> Greg Smith <greg(at)2ndquadrant(dot)com> writes:
>
>> What I was trying to suggest was that right now, there are situations
>> where a new deployment on 8.1 is still completely reasonable and
>> possible to justify in the Enterprise Linux space, whereas I don't know
>> of any situation where 7.4/8.0 can be similarly defended as a good
>> idea.
>>
>
> Okay, but how much of the argument for that hinges on it being the only
> thing Red Hat will support on RHEL5?
>
Sure, at some point in 2010, we may reach a point where it would be ill
advised to build a new system using RHEL5/PG8.1. I was suggesting more
that there are completely reasonable reasons to deploy 8.1 even right
now in 2009, and people are doing so. That gives the release a lot more
future than 7.4 and 8.0, which anyone sensible gave up on a while ago.
I'm all for dropping those older ones, but I don't think getting more
aggressive than that and bundling 8.1 in while you're at it is so wise.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

On Tue, Dec 1, 2009 at 10:40 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:

> Sure, at some point in 2010, we may reach a point where it would be ill
> advised to build a new system using RHEL5/PG8.1.  I was suggesting more that
> there are completely reasonable reasons to deploy 8.1 even right now in
> 2009, and people are doing so.  That gives the release a lot more future
> than 7.4 and 8.0, which anyone sensible gave up on a while ago.  I'm all for
> dropping those older ones, but I don't think getting more aggressive than
> that and bundling 8.1 in while you're at it is so wise.

I think 8.2 is the first release with a vacuum that doesn't completely
thrash your i/o. Also the first one where you could effectively use
partitioning because you could actually add and drop partitions. Also
the first one with concurrent index builds. I can't imagine supporting
recommending 8.1 for anything but a toy deployment today.

I still insist it's unrealistic to consider any of these, even 8.2, as
anything but "best effort" at this point. Declaring 8.0 "end of life"
today is implying that we haven't already been skipping fixing bugs in
it that would have required major changes. People running 8.1 and 8.2
should be given the truth that only really important bugs are going to
cause any significant development for these versions. Otherwise
they're only going to get fixes that are simple and small enough that
the patches from later versions apply cleanly without major code
changes. This isn't out of laziness, it's because we know there are
existing installations depending on these releases and we don't want
to risk breaking them with major chunks of new code or fixing bugs
some people could be relying on unwittingly.

--
greg

Greg Stark wrote:
> I can't imagine supporting recommending 8.1 for anything but a toy deployment today.
>
Today's toy and test deployments are tomorrow's high-volume ones. It's
pretty clear that anyone who cares about performance wants something
newer. But that's a secondary concern behind security and easy of
management for some installations, and some of those think that using
the RHEL packages is the best way to achieve those goals. I'd hate for
people who are considering proof-of-concept projects that tinker using
the version that comes with the OS to get a bad feeling about that
version by seeing it EOL'd earlier than it has to. That ship has
clearly sailed for RHEL4 and it's 7.4 already--nobody considers the
packages that come with it reasonable to start a new project with
anymore--but I don't think it has for RHEL5/8.1 yet, based on what I've
been seeing over the last year in the field.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

Greg Stark <gsstark(at)mit(dot)edu> writes:
> I still insist it's unrealistic to consider any of these, even 8.2, as
> anything but "best effort" at this point.

Agreed, and we should not pretend otherwise.

> Declaring 8.0 "end of life"
> today is implying that we haven't already been skipping fixing bugs in
> it that would have required major changes. People running 8.1 and 8.2
> should be given the truth that only really important bugs are going to
> cause any significant development for these versions.

The other side of the coin is that people running such old versions are
in it for stability --- they don't *want* bugs fixed, unless they're
bugs they've hit themselves. Major fixes that would possibly
destabilize the code base would be exactly what's not wanted. Every
time I get Red Hat to ship an update version, it's only after fighting
tooth and nail to do a "rebase" instead of cherry-picking just the fixes
for bugs that paying customers have specifically complained about. The
fact that we're pretty conservative about what we back-patch is the only
reason I ever win any of those arguments.

regards, tom lane

Tom Lane wrote:
> The other side of the coin is that people running such old versions are
> in it for stability --- they don't *want* bugs fixed, unless they're
> bugs they've hit themselves. Major fixes that would possibly
> destabilize the code base would be exactly what's not wanted. Every
> time I get Red Hat to ship an update version, it's only after fighting
> tooth and nail to do a "rebase" instead of cherry-picking just the fixes
> for bugs that paying customers have specifically complained about. The
> fact that we're pretty conservative about what we back-patch is the only
> reason I ever win any of those arguments.
>
>
>

I don't find anything wrong with this picture. The other upside of our
being conservative about what we back-patch is that users have much more
confidence in the community edition. If we were less so, we'd find more
users on older, vendor-supported versions, which would be more out of
date than they are now, for the reasons Tom outlines above.

cheers

andrew

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Mark wrote:
> Doesn't mean that packagers have to make new packages ... I personally
> think new packages shouldn't be made for anything older then *maybe* 3
> releases (8.2, 8.3 and 8.4), but even that I think tends to be a bit
> excessive ... but doing source tar balls is easy enough ...

Andrew wrote:
> But the issue for me is not what vendors support but how often we ask
> someone to upgrade if they want to stay on a community supported base.
> As I remarked before, other things being equal, I think five years is a
> reasonable interval, and given that many users don't upgrade right on a
> .0 release, I think a release lifetime of about six years is therefore
> about right as a target.

All of this ignores a huge reason why we have an implicit obligation to
support past releases for a long time: our horrible lack of an upgrade
option. That's only now starting to get remedied somewhat with pg_migrator,
Bucardo, and Slony, but the default way is still to do a dump-and-restore.
Until we can make this process take minutes instead of days for large databases,
people are going to end up stuck to what version they are on. Knowing
they are going to have to do it all over again later is not going to
be very confidence inspiring.

Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because
they necessarily want to, but they can't easily afford the downtime to
upgrade. Cutting them off arbitrarily early won't win us any friends. Once
pg_migrator (or better, in-place upgrades) is working well, we can start setting
EOL on versions based on number of years of some other criteria.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation
PGP Key: 0x14964AC8 200912021218
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAksWokQACgkQvJuQZxSWSsg5kACfdd9nZtHSG/KcOAIOGxVZ81/o
TUEAniaG4vWo4CY4v+3DlByJ4AZ6JXKP
=MyN9
-----END PGP SIGNATURE-----

On Wed, Dec 2, 2009 at 12:22 PM, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote:
> Mark wrote:
>> Doesn't mean that packagers have to make new packages ... I personally
>> think new packages shouldn't be made for anything older then *maybe* 3
>> releases (8.2, 8.3 and 8.4), but even that I think tends to be a bit
>> excessive ... but doing source tar balls is easy enough ...
>
> Andrew wrote:
>> But the issue for me is not what vendors support but how often we ask
>> someone to upgrade if they want to stay on a community supported base.
>> As I remarked before, other things being equal, I think five years is a
>> reasonable interval, and given that many users don't upgrade right on a
>> .0 release, I think a release lifetime of about six years is therefore
>> about right as a target.
>
> All of this ignores a huge reason why we have an implicit obligation to
> support past releases for a long time: our horrible lack of an upgrade
> option. That's only now starting to get remedied somewhat with pg_migrator,
> Bucardo, and Slony, but the default way is still to do a dump-and-restore.
> Until we can make this process take minutes instead of days for large databases,
> people are going to end up stuck to what version they are on. Knowing
> they are going to have to do it all over again later is not going to
> be very confidence inspiring.
>
> Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because
> they necessarily want to, but they can't easily afford the downtime to
> upgrade. Cutting them off arbitrarily early won't win us any friends. Once
> pg_migrator (or better, in-place upgrades) is working well, we can start setting
> EOL on versions based on number of years of some other criteria.

At the moment it doesn't seem likely that pg_migrator is *ever* going
to support upgrading from 7.4 or 8.0 or 8.1 to any later version.

I'm not saying that's good, but nobody's expressed much interest in
making in-place upgrade work even from an 8.2 base, let alone any
older version. For that matter, there's been no concerted effort to
resolve the limitations of the 8.3 -> 8.4 upgrade. It isn't
technically impossible for the 8.3 -> 8.5 path to be smoother than the
current 8.3 -> 8.4 path, but nobody seems excited about working on it.

...Robert

Dave Page wrote:
> On Tue, Dec 1, 2009 at 4:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> ... 8.1 in RHEL5 ...

+1 for letting 7.* and 8.0 die whenever no-one's
motivated to bother supporting it anymore.

> Presumably you'll be on the hook until 2014 for 8.1 security patches
> I can't see the community wanting to support it for that long

-1 for letting 8.1 die while someone major still supporting it,
even if that means EOLing 8.2 before 8.1.

As a PG user, it's confidence inspiring to see a project that
can provide 7-years of support on a version.

As a Red Hat customer, I'd feel happier if my database were not
considered dead by the upstream community.

It also feels more in the spirit of open-source to me -- where
if one member is willing to put in work (Red Hat/Tom), the benefits
are shared back; and in exchange the rest of the community can help
with that contribution.

> I'm for EOLing *at least* 7.4 and 8.0 by January 2011, and I'm
> certainly not going to argue against doing the same for 8.1. Frankly,
> I think we could do 7.4 and maybe 8.0 six months earlier.

I think the best would be to say 7.4 and 8.0 end in Jan 2011,
and 8.1 switches to only high-priority security patches at that
date.

Robert Haas wrote:
> > Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because
> > they necessarily want to, but they can't easily afford the downtime to
> > upgrade. Cutting them off arbitrarily early won't win us any friends. Once
> > pg_migrator (or better, in-place upgrades) is working well, we can start setting
> > EOL on versions based on number of years of some other criteria.
>
> At the moment it doesn't seem likely that pg_migrator is *ever* going
> to support upgrading from 7.4 or 8.0 or 8.1 to any later version.

Agreed.

> I'm not saying that's good, but nobody's expressed much interest in
> making in-place upgrade work even from an 8.2 base, let alone any
> older version. For that matter, there's been no concerted effort to
> resolve the limitations of the 8.3 -> 8.4 upgrade. It isn't
> technically impossible for the 8.3 -> 8.5 path to be smoother than the
> current 8.3 -> 8.4 path, but nobody seems excited about working on it.

Agreed.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Robert Haas wrote:
>> Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because
>> they necessarily want to, but they can't easily afford the downtime to
>> upgrade. Cutting them off arbitrarily early won't win us any friends. Once
>> pg_migrator (or better, in-place upgrades) is working well, we can start setting
>> EOL on versions based on number of years of some other criteria.
>>
>
> At the moment it doesn't seem likely that pg_migrator is *ever* going
> to support upgrading from 7.4 or 8.0 or 8.1 to any later version.
>
> I'm not saying that's good, but nobody's expressed much interest in
> making in-place upgrade work even from an 8.2 base, let alone any
> older version. For that matter, there's been no concerted effort to
> resolve the limitations of the 8.3 -> 8.4 upgrade. It isn't
> technically impossible for the 8.3 -> 8.5 path to be smoother than the
> current 8.3 -> 8.4 path, but nobody seems excited about working on it.
>
>
>

Migration is really only half the story, or not even that much. Every
time you move to a new Postgres version you have to do extensive work to
revalidate your application. If you don't do that you're just asking for
trouble. But it can be painful, expensive and disruptive. I know of
places where it can take weeks or months of effort. So the less often
you have to do it the better. This would be true even if we had had a
perfect working inplace upgrade mechanism for years, which as you and
Greg point out is not true.

I don't have any clients who don't/can't upgrade because they can't
manage the downtime, but I have more than one avoiding upgrade because
of revalidation costs.

cheers

andrew

On Wed, Dec 2, 2009 at 7:53 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> At the moment it doesn't seem likely that pg_migrator is *ever* going
>> to support upgrading from 7.4 or 8.0 or 8.1 to any later version.
>
> Agreed.

The problem is that the development effort to migrate data that was
never designed to be migratable is completely out of scale from the
benefits. You can solve problems pg_migrator has much more easily and
with less damage to the code by putting the hooks into the server
rather than making pg_migrator muck about inside the data structures
fixing things.

For example to deal with the problem of dropped columns we could add
hooks to CREATE TABLE to allow pg_migrator to specify the physical
order of columns. To do it without modifying the server pg_migrator
has to play tricks by running updates against the catalog tables. And
there are worse problems than that -- toast tables would require
massive amounts of code in the new version to migrate but we found
some simple tweaks to the toast format which eliminate the whole
problem going forward.

--
greg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> Migration is really only half the story, or not even that much. Every
> time you move to a new Postgres version you have to do extensive work to
> revalidate your application. If you don't do that you're just asking for
> trouble. But it can be painful, expensive and disruptive. I know of
> places where it can take weeks or months of effort. So the less often
> you have to do it the better. This would be true even if we had had a
> perfect working inplace upgrade mechanism for years, which as you and
> Greg point out is not true.

I don't agree with this - migration is much more important than you make out.
Testing and validation can be a pain, but it can be done concurrently while
your main production site is still chugging along and taking orders. At some
point, however, migration *will* cause production downtime[1]. This is one of
the Achilles' heel of Postgres, and I'm frankly surprised it has taken us
this long to get pg_migrator to a somewhat working state.

> I don't have any clients who don't/can't upgrade because they can't
> manage the downtime, but I have more than one avoiding upgrade because
> of revalidation costs.

Well, I certainly had many clients who had major problems dealing with
the implicit casts removed in 8.3, but there are also some in which the
sheer size of the database is a factor as well. I think Robert Treat
can probably chime in on some upgrade woes here too.

[1] Okay, there are some tricks to work around this or severely minimize
the downtime </Bucardo_plug>, but it's still a truism that upgrading versions
is a pain and nearly always involves production downtime.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200912040846
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAksZEqMACgkQvJuQZxSWSsgGyACdEyfIqwFsFrt9ZnQ2DNPVYIWP
j08AoK+cLC84HSjlIbzJY8Gz/gAa6D74
=AzuV
-----END PGP SIGNATURE-----