Thread: 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@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 anythingof 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 "PostgreSQLrelease version n.n. will reach the end of its maintenance life on yyyy-mm-dd. No patches of any kind will bemade 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 versioncomes out, they want to let it settle down. And they also don't want to have to go through the pain of migrating morethan once every few years - five would be a good number here. (This has nothing to do with whether or not we have inplace upgrade. It's more to do with the effort involved in revalidating a large application against a new release.) Soallowing 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 HaganderMe: 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 anythingof mine in it ;-) >> >> What I want is a proper process for declaring an EOL, though. In particular, we should announce it loudly and well inadvance (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 willbe 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 HaganderMe: 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 www.2ndQuadrant.com > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
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
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@agliodbs.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@turnstep.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@turnstep.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@2ndQuadrant.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@sonic.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@2ndQuadrant.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@turnstep.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@dunslane.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@turnstep.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@turnstep.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@sonic.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@momjian.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@sonic.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@momjian.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 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
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 Fri, Nov 13, 2009 at 02:47:56AM +0000, Greg Stark wrote: > On Fri, Nov 13, 2009 at 2:35 AM, daveg <daveg@sonic.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@sonic.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@turnstep.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@turnstep.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@sss.pgh.pa.us> wrote: > "Greg Sabino Mullane" <greg@turnstep.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@turnstep.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@hub.org http://www.hub.org Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy@hub.org
"Marc G. Fournier" <scrappy@hub.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@sss.pgh.pa.us> wrote: > "Marc G. Fournier" <scrappy@hub.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@dunslane.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@2ndQuadrant.com www.2ndQuadrant.com
Greg Smith <greg@2ndquadrant.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@2ndquadrant.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@2ndQuadrant.com www.2ndQuadrant.com
Greg Smith <greg@2ndquadrant.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: <blockquote cite="mid:23576.1259705665@sss.pgh.pa.us" type="cite"><pre wrap="">Greg Smith <a class="moz-txt-link-rfc2396E"href="mailto:greg@2ndquadrant.com"><greg@2ndquadrant.com></a> writes: </pre><blockquotetype="cite"><pre wrap="">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. </pre></blockquote><pre wrap=""> Okay, but how much of the argument for that hinges on it being the only thing Red Hat will support on RHEL5? </pre></blockquote> Sure, at some point in 2010, we may reach a point where it wouldbe ill advised to build a new system using RHEL5/PG8.1. I was suggesting more that there are completely reasonablereasons to deploy 8.1 even right now in 2009, and people are doing so. That gives the release a lot more futurethan 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'tthink getting more aggressive than that and bundling 8.1 in while you're at it is so wise.<br /><br /><pre class="moz-signature"cols="72">-- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support <a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a> <a class="moz-txt-link-abbreviated"href="http://www.2ndQuadrant.com">www.2ndQuadrant.com</a> </pre>
On Tue, Dec 1, 2009 at 10:40 PM, Greg Smith <greg@2ndquadrant.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@2ndQuadrant.com www.2ndQuadrant.com
Greg Stark <gsstark@mit.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@turnstep.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@turnstep.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@sss.pgh.pa.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@momjian.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@momjian.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@turnstep.com PGP Key: 0x14964AC8 200912040846 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAksZEqMACgkQvJuQZxSWSsgGyACdEyfIqwFsFrt9ZnQ2DNPVYIWP j08AoK+cLC84HSjlIbzJY8Gz/gAa6D74 =AzuV -----END PGP SIGNATURE-----