Re: [HACKERS] Maintenance Policy?
Tom Lane wrote: I'd suggest that we publish an official policy, with the following dates for EOL: But on the whole I think we should NOT have such a policy, at all. [...] If someone wants a guaranteed EOL date, they ought to be contracting with a commercial support company and paying appropriately. +1 (for not having EOL dates) Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
Josh Berkus j...@agliodbs.com wrote: after the final minor release date, there is no guarantee INAL, but that *seems* like it might open the community or its members to lawsuits based on an implied guarantee up to the final minor release date. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
Josh Berkus wrote: I'd suggest that we publish an official policy, with the following dates for EOL: 7.4 2009-08-01 ... 8.4 2014-08-01 What would such forward-looking statements even mean for a community-driven project? I assume for a commercial product, such a statement would mean something like I could get my money back or sue for breach of contract or similar if the vendor stops providing support before such a date. For an open source project, would such a statement really mean anything more than we'll provide support as long as some community members feel like it, and we guess that's about 5 years? If so, what? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
For an open source project, would such a statement really mean anything more than we'll provide support as long as some community members feel like it, and we guess that's about 5 years? Well, what I'm really concerned about is letting people know that we expect to *stop* providing update versions after 5 years. Every year, this seems to take some people by surprise. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
On Sun, Jul 12, 2009 at 11:53 PM, Josh Berkusj...@agliodbs.com wrote: Well, what I'm really concerned about is letting people know that we expect to *stop* providing update versions after 5 years. That seems like a reasonable thing to say and you've just said it more simply than any of your previous proposals. I suggest you just go with the above. Every year, this seems to take some people by surprise. For what it's worth I find it hard to believe anyone's really surprised by this. Nearly all other open source projects stop supporting old branches as soon as there's a newer branch is released. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 For what it's worth I find it hard to believe anyone's really surprised by this. Nearly all other open source projects stop supporting old branches as soon as there's a newer branch is released. I'm not surprised at all. Our product holds data - and that's an extremely valuable resource to end users (e.g. companies). Nobody wants to risk problems and/or suffer long downtimes. Our complete lack of an in-place upgrade is what is really making us do the extra effort to support old versions. Thankfully, it looks like we've finally started down the road to a serious attempt at an upgrade process. For what it's worth, I think our release history and current necessarily ad-hoc and somewhat arbitrary release process makes it difficult to make anything but the vaguest statement on dates, and I'd rather we didn't. - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200907122044 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkpahQkACgkQvJuQZxSWSsjehACg7208VOSWEoJuHWMORnhAg82t IugAn0vSGBI9qUvAUDb3msMeyRzjjuy7 =tcmE -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
Greg Sabino Mullane wrote: [ There is text before PGP section. ] -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 For what it's worth I find it hard to believe anyone's really surprised by this. Nearly all other open source projects stop supporting old branches as soon as there's a newer branch is released. I'm not surprised at all. Our product holds data - and that's an extremely valuable resource to end users (e.g. companies). Nobody wants to risk problems and/or suffer long downtimes. Our complete lack of an in-place upgrade is what is really making us do the extra effort to support old versions. Thankfully, it looks like we've finally started down the road to a serious attempt at an upgrade process. For what it's worth, I think our release history and current necessarily ad-hoc and somewhat arbitrary release process makes it difficult to make anything but the vaguest statement on dates, and I'd rather we didn't. This might open the larger question of: What do we actually _promise_ users? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
On Mon, Jul 13, 2009 at 2:07 AM, Bruce Momjianbr...@momjian.us wrote: This might open the larger question of: What do we actually _promise_ users? The discussion had already covered that ground. If someone wants a promise they'll have to fork over money to one of the companies which sell such things. That's why Josh's last email where he said just that we *didn't* plan to support releases for longer than 5 years is much better than the other attempts to say how long we *did* plan to support releases. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
Greg Stark wrote: On Mon, Jul 13, 2009 at 2:07 AM, Bruce Momjianbr...@momjian.us wrote: This might open the larger question of: ?What do we actually _promise_ users? The discussion had already covered that ground. If someone wants a promise they'll have to fork over money to one of the companies which sell such things. That's why Josh's last email where he said just that we *didn't* plan to support releases for longer than 5 years is much better than the other attempts to say how long we *did* plan to support releases. Interesting distinction. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
Hmmm, how about this? The current policy of the PostgreSQL community is to stop providing minor versions (patches or updates) of PostgreSQL five years after a version of PostgreSQL is released. In general, users can expect to continue to be able to get community updates for five years. However, there have been exceptions in both directions. Some companies choose to continue back-patching PostgreSQL and make those updates available to the community past the fifth anniversary. Other times issues with build tools have caused us to discontinue a particular version early, such as 8.0 and 8.1 for Windows, which stopped getting updates in binary form after only 2 years. Overall, if you have specific lifetime requirements for your database products, we strongly urge you to get a long-term support contract with a PostgreSQL support vendor link. As examples of this policy, below are the dates at which updates of specific version became unavailable: table here -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
Josh Berkus wrote: Hmmm, how about this? The current policy of the PostgreSQL community is to stop providing minor versions (patches or updates) of PostgreSQL five years after a version of PostgreSQL is released. I think this is putting it the wrong way round. We should say that the general intention is to maintain a version for at least five years, or some similar formulation. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
All, I'd suggest that we publish an official policy, with the following dates for EOL: 7.4 2009-08-01 8.0 2010-02-01 8.1 2011-01-01 8.2 2012-01-01 8.3 2013-03-01 8.4 2014-08-01 EOL would be defined as: After the above dates, the PostgreSQL Project will not promise to provide any minor (patch or update) releases of the respective versions, whether for security, data loss, or any other issue. Individual companies might choose to continue backporting patches to earlier versions, and if they contribute these update releases we will make them available. However, after the final minor release date, there is no guarantee that updates will be available and users should upgrade. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
On Jul 10, 2009, at 4:01 PM, Josh Berkus wrote: All, I'd suggest that we publish an official policy, with the following dates for EOL: 7.4 2009-08-01 8.0 2010-02-01 8.1 2011-01-01 8.2 2012-01-01 8.3 2013-03-01 8.4 2014-08-01 EOL would be defined as: After the above dates, the PostgreSQL Project will not promise to provide any minor (patch or update) releases of the respective versions, whether for security, data loss, or any other issue. Individual companies might choose to continue backporting patches to earlier versions, and if they contribute these update releases we will make them available. However, after the final minor release date, there is no guarantee that updates will be available and users should upgrade. +1 It's useful to have the version number and date of the most recent release too, but this is the important stuff. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
Josh Berkus j...@agliodbs.com writes: I'd suggest that we publish an official policy, with the following dates for EOL: 7.4 2009-08-01 8.0 2010-02-01 8.1 2011-01-01 8.2 2012-01-01 8.3 2013-03-01 8.4 2014-08-01 I have no objection to setting an EOL date for 7.4 now, but I think it is premature to set EOL dates for later versions. I suppose the policy you have in mind here (but are not spelling out) is that versions will be EOL'd five years after release no matter what. I'm not convinced that we need to have a policy for that at all; but if we were to set one, I'd prefer to define it in terms of the maximum number of back branches we want to deal with. (So it'd go more like a version will be EOL'd shortly after the release of the fifth subsequent major version.) Or, if you want something calendar-based, it should be driven off the release of the immediately following major version (i.e., not less than four years after the release of the next major version), so that people would always know that they have at least N years' support when they adopt the current major version. But on the whole I think we should NOT have such a policy, at all. If we'd enunciated such a thing in 2005, we'd still be on the hook to support 8.0 on Windows; or else have had to go back on our word. The truth of the matter is that the community will make reasonable efforts to support back branches but we are not going to set anything in stone. If someone wants a guaranteed EOL date, they ought to be contracting with a commercial support company and paying appropriately. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
David E. Wheeler wrote: On Jul 10, 2009, at 4:01 PM, Josh Berkus wrote: All, I'd suggest that we publish an official policy, with the following dates for EOL: 7.4 2009-08-01 8.0 2010-02-01 8.1 2011-01-01 8.2 2012-01-01 8.3 2013-03-01 8.4 2014-08-01 EOL would be defined as: After the above dates, the PostgreSQL Project will not promise to provide any minor (patch or update) releases of the respective versions, whether for security, data loss, or any other issue. Individual companies might choose to continue backporting patches to earlier versions, and if they contribute these update releases we will make them available. However, after the final minor release date, there is no guarantee that updates will be available and users should upgrade. +1 It's useful to have the version number and date of the most recent release too, but this is the important stuff. We haven't committed to something like this in the past but it is probably time where we can't avoid it. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
On Jul 10, 2009, at 6:01 PM, Josh Berkus j...@agliodbs.com wrote: All, I'd suggest that we publish an official policy, with the following dates for EOL: 7.4 2009-08-01 8.0 2010-02-01 8.1 2011-01-01 8.2 2012-01-01 8.3 2013-03-01 8.4 2014-08-01 EOL would be defined as: After the above dates, the PostgreSQL Project will not promise to provide any minor (patch or update) releases of the respective versions, whether for security, data loss, or any other issue. Individual companies might choose to continue backporting patches to earlier versions, and if they contribute these update releases we will make them available. However, after the final minor release date, there is no guarantee that updates will be available and users should upgrade. It seems pretty speculative to propose end of support dates for every active release at this point; what if it takes us longer than planned to get the next few releases out? I think we could try to set dates for the older releases. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
Tom Lane wrote: But on the whole I think we should NOT have such a policy, at all. If we'd enunciated such a thing in 2005, we'd still be on the hook to support 8.0 on Windows; or else have had to go back on our word. The truth of the matter is that the community will make reasonable efforts to support back branches but we are not going to set anything in stone. If someone wants a guaranteed EOL date, they ought to be contracting with a commercial support company and paying appropriately. I think we can avoid most of these problems by making a best effort policy rather than a hard promise. But it can be moderately specific about what we will make best efforts towards. I agree that anyone who wants a hard promise should be getting commercial support. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
Andrew Dunstan and...@dunslane.net writes: I think we can avoid most of these problems by making a best effort policy rather than a hard promise. But it can be moderately specific about what we will make best efforts towards. I agree that anyone who wants a hard promise should be getting commercial support. I don't mind the idea of saying our intention is to support new releases for about five years, or something equally squishy. But a list of dates in black and white does not look reasonable, especially not dates that are four or five years out for versions that have zero track record. We have no idea whatsoever what the future will bring. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: I think we can avoid most of these problems by making a best effort policy rather than a hard promise. But it can be moderately specific about what we will make best efforts towards. I agree that anyone who wants a hard promise should be getting commercial support. I don't mind the idea of saying our intention is to support new releases for about five years, or something equally squishy. But a list of dates in black and white does not look reasonable, especially not dates that are four or five years out for versions that have zero track record. We have no idea whatsoever what the future will bring. Would it be reasonable to have the squishy intention coupled with a more firm policy of ...EOL will be announced X months in advance...Users requiring firm long-term EOL commitments are advised to purchase commercial support... Perhaps the postgresql.org home-page should be modified slightly. Instead of Latest Releases (which doesn't even list 7.4 when I just looked), it could be something like Current Releases. Then when EOL is announced, the release could be suffixed with the EOL date (i.e. 7.4.25 EOL 2009-12-31 - maybe even with the EOL date in bold and/or red) which would link to the EOL announcement or general EOL statement page. I think that a EOL Statement link to a page with the generic statement placed just below the oldest release could be helpful as well. Cheers, Steve
Re: [HACKERS] Maintenance Policy?
On Jul 10, 2009, at 5:39 PM, Tom Lane wrote: I don't mind the idea of saying our intention is to support new releases for about five years, or something equally squishy. But a list of dates in black and white does not look reasonable, especially not dates that are four or five years out for versions that have zero track record. We have no idea whatsoever what the future will bring. I think that it would be useful to have the squish comment, but also a list of versions that are definitely no longer supported, and when support ceased. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
On Fri, 10 Jul 2009 19:51:31 -0400 Tom Lane t...@sss.pgh.pa.us wrote: Josh Berkus j...@agliodbs.com writes: I'd suggest that we publish an official policy, with the following dates for EOL: I have no objection to setting an EOL date for 7.4 now, but I think it is premature to set EOL dates for later versions. I suppose the policy you have in mind here (but are not spelling out) is that versions will be EOL'd five years after release no matter what. I'm not convinced How about five (or four or...) years after the next version is released? That takes into account longer release schedules. That way we aren't guaranteeing support for a hard term for a release but rather that we will support it for a specified time from the date it is superceded by the next version. -- D'Arcy J.M. Cain da...@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
David E. Wheeler wrote: Howdy Hackers, Is there a published maintenance policy somewhere? Something that says for how long the project supports minor releases of PostgreSQL. We don't have a published policy, but I believe an unofficial policy has been to support minor releases for about 5 years. For example, does 7.4 still get bug fixes and minor releases? If not, how does one know when support for a major version has been dropped? Hmm, I thought we dropped support for 7.4 a while ago, and there's no download link for it on www.postgresql.org anymore. But looking at the CVS history, I see that others are still committing fixes to 7.4 branch. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
On Tue, Jul 7, 2009 at 8:28 AM, Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote: For example, does 7.4 still get bug fixes and minor releases? If not, how does one know when support for a major version has been dropped? Hmm, I thought we dropped support for 7.4 a while ago, and there's no download link for it on www.postgresql.org anymore. But looking at the CVS history, I see that others are still committing fixes to 7.4 branch. We dropped the link when we released 8.4, primarily for space reasons. I believe Tom is still patching 7.4 though as Redhat have obligations to support it and he'd have to do it regardless of project policy. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
Heikki Linnakangas wrote: David E. Wheeler wrote: Howdy Hackers, Is there a published maintenance policy somewhere? Something that says for how long the project supports minor releases of PostgreSQL. We don't have a published policy, but I believe an unofficial policy has been to support minor releases for about 5 years. My recollection is that we don't have a maximum lifetime, but we do have a minimum lifetime of about two release cycles, whic is in practice about 2 to 2.5 years. Beyond that, we try to maintain the branches as long as the effort is not too great. When the branches become unmaintainable they are dropped. For example, does 7.4 still get bug fixes and minor releases? If not, how does one know when support for a major version has been dropped? Hmm, I thought we dropped support for 7.4 a while ago, and there's no download link for it on www.postgresql.org anymore. But looking at the CVS history, I see that others are still committing fixes to 7.4 branch. Indeed we are :-) I don't recall any decision not to continue support for 7.4, which is still quite solid, if a bit limited. (I had to help rescue somebody who had been running 6.5 recently, so don't think people aren't running extremely old branches.) If you're going to backpatch something, going back a couple more branches is often not a great difficulty, unless the code drift is large. Most backpatches are relatively limited in scope. If there is something that is invasive and difficult, that's a possible reason to drop support. Most users don't want to be upgrading all the time, and I believe we inspire some confidence in our user base by a) being quite conservative about what we backpatch, and b) giving our stable branches quite long lifetimes. BTW, 7.4 is less than six years old. If we were going to impose an arbitrary branch lifetime limit, I think five or six years is about right. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
Dave Page dp...@pgadmin.org writes: On Tue, Jul 7, 2009 at 8:28 AM, Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote: Hmm, I thought we dropped support for 7.4 a while ago, and there's no download link for it on www.postgresql.org anymore. But looking at the CVS history, I see that others are still committing fixes to 7.4 branch. We dropped the link when we released 8.4, primarily for space reasons. I believe Tom is still patching 7.4 though as Redhat have obligations to support it and he'd have to do it regardless of project policy. I'm still theoretically on the hook for 7.3, too. In practice I doubt I'd be able to get any but really critical security updates into RHEL-3 or RHEL-4 at this point, so the notion that we're supporting these old versions because Red Hat wants 'em is probably not holding any water anymore. I'd personally be perfectly happy with a community decision to desupport 7.4 now, or perhaps after the next set of update releases (which we're probably overdue for, BTW). We cannot support an indefinitely large set of back branches, and a five-year lifespan seems about right to me. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
On Jul 7, 2009, at 8:06 AM, Tom Lane wrote: I'd personally be perfectly happy with a community decision to desupport 7.4 now, or perhaps after the next set of update releases (which we're probably overdue for, BTW). We cannot support an indefinitely large set of back branches, and a five-year lifespan seems about right to me. I had kind of thought it was five active versions, which translates to more or less the same thing. In that case, 7.4 would shortly be dropped. So I ask: 1. Should 7.4 be dropped after the release of 7.4.26? 2. Should there be an articulated, published maintenance policy? Or, at least, a prominent list saying, these are the versions we actively support as of now? Thanks, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
David E. Wheeler wrote: On Jul 7, 2009, at 8:06 AM, Tom Lane wrote: I'd personally be perfectly happy with a community decision to desupport 7.4 now, or perhaps after the next set of update releases (which we're probably overdue for, BTW). We cannot support an indefinitely large set of back branches, and a five-year lifespan seems about right to me. I had kind of thought it was five active versions, which translates to more or less the same thing. In that case, 7.4 would shortly be dropped. So I ask: 1. Should 7.4 be dropped after the release of 7.4.26? 2. Should there be an articulated, published maintenance policy? Or, at least, a prominent list saying, these are the versions we actively support as of now? One thing I think we really should do is give prominent public notice of any EOL for a branch. At least a couple of months, preferably. If the lifetime were absolutely fixed it might not matter so much, but as it isn't I think we owe that to our users. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote: One thing I think we really should do is give prominent public notice of any EOL for a branch. At least a couple of months, preferably. If the lifetime were absolutely fixed it might not matter so much, but as it isn't I think we owe that to our users. Perhaps a maintenance page on the site with a table for each version of PostgreSQL, in reverse chronological order, showing the initial release date and the date of last supported release (anticipated, perhaps, to be something like Sept 1 for 7.4). So something like: branch | released | curr_version | curr_date | final_date ++--++ 8.4| 2009-07-01 | 8.4.0| 2009-07-01 | 8.3| 2008-02-04 | 8.3.7| 2009-03-16 | 8.2| 2006-12-05 | 8.2.13 | 2009-03-16 | 8.1| 2005-11-08 | 8.1.17 | 2009-03-16 | 8.0| 2005-01-19 | 8.0.21 | 2009-03-16 | 7.4| 2003-11-17 | 7.4.25 | 2009-03-16 | 2009-09-01 (projected) 7.3| 2002-11-27 | 7.3.21 | 2008-01-07 | 2008-01-07 7.2| 2002-02-04 | 7.2.8| 2005-05-09 | 2005-05-09 7.1| 2001-04-13 | 7.1.3| 2001-08-15 | 2001-08-15 7.0| 2000-05-08 | 7.0.3| 2000-11-11 | 2000-11-11 Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
David E. Wheeler wrote: On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote: One thing I think we really should do is give prominent public notice of any EOL for a branch. At least a couple of months, preferably. If the lifetime were absolutely fixed it might not matter so much, but as it isn't I think we owe that to our users. Perhaps a maintenance page on the site with a table for each version of PostgreSQL, in reverse chronological order, showing the initial release date and the date of last supported release (anticipated, perhaps, to be something like Sept 1 for 7.4). We have an RSS: http://www.postgresql.org/versions.rss -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
On Jul 7, 2009, at 10:18 AM, Alvaro Herrera wrote: We have an RSS: http://www.postgresql.org/versions.rss Does anyone use it? And it only goes back to 8.0 and it served with the text/html content-type. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
David E. Wheeler wrote: On Jul 7, 2009, at 10:18 AM, Alvaro Herrera wrote: We have an RSS: http://www.postgresql.org/versions.rss Does anyone use it? No idea. And it only goes back to 8.0 Huh, true :-( This should be fixed. and it served with the text/html content-type. Not for me: $ lynx -head -dump http://www.postgresql.org/versions.rss HTTP/1.1 200 OK Date: Tue, 07 Jul 2009 18:56:48 GMT Server: Apache Last-Modified: Wed, 01 Jul 2009 11:25:40 GMT ETag: bd2589-a8d-46da32eda5500 Accept-Ranges: bytes Content-Length: 2701 Connection: close Content-Type: application/rss+xml I guess it depends on the mirror. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
On Jul 7, 2009, at 11:59 AM, Alvaro Herrera wrote: And it only goes back to 8.0 Huh, true :-( This should be fixed. Yeah. Or we should have a table. I could create one in the wiki, I guess, but I would assume that the core team would want to have formal control over scheduled maintenance expirations… and it served with the text/html content-type. Not for me: $ lynx -head -dump http://www.postgresql.org/versions.rss HTTP/1.1 200 OK Date: Tue, 07 Jul 2009 18:56:48 GMT Server: Apache Last-Modified: Wed, 01 Jul 2009 11:25:40 GMT ETag: bd2589-a8d-46da32eda5500 Accept-Ranges: bytes Content-Length: 2701 Connection: close Content-Type: application/rss+xml I guess it depends on the mirror. Right: % curl -I http://en.wikipedia.org/wiki/Nofollow HTTP/1.0 200 OK Date: Tue, 07 Jul 2009 07:37:07 GMT Server: Apache X-Powered-By: PHP/5.2.4-2ubuntu5wm1 Cache-Control: private, s-maxage=0, max-age=0, must-revalidate Content-Language: en Vary: Accept-Encoding,Cookie X-Vary-Options: Accept-Encoding;list-contains=gzip,Cookie;string- contains=enwikiToken;string-contains=enwikiLoggedOut;string- contains=enwiki_session;string-contains=centralauth_Token;string- contains=centralauth_Session;string-contains=centralauth_LoggedOut Last-Modified: Mon, 06 Jul 2009 21:52:17 GMT Content-Length: 55543 Content-Type: text/html; charset=utf-8 Age: 41449 X-Cache: HIT from sq21.wikimedia.org X-Cache-Lookup: HIT from sq21.wikimedia.org:3128 X-Cache: MISS from sq22.wikimedia.org X-Cache-Lookup: MISS from sq22.wikimedia.org:80 Via: 1.1 sq21.wikimedia.org:3128 (squid/2.7.STABLE6), 1.0 sq22.wikimedia.org:80 (squid/2.7.STABLE6) Connection: close Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
David E. Wheeler wrote: On Jul 7, 2009, at 9:13 AM, Andrew Dunstan wrote: One thing I think we really should do is give prominent public notice of any EOL for a branch. At least a couple of months, preferably. If the lifetime were absolutely fixed it might not matter so much, but as it isn't I think we owe that to our users. Perhaps a maintenance page on the site with a table for each version of PostgreSQL, in reverse chronological order, showing the initial release date and the date of last supported release (anticipated, perhaps, to be something like Sept 1 for 7.4). So something like: branch | released | curr_version | curr_date | final_date ++--++ 8.4| 2009-07-01 | 8.4.0| 2009-07-01 | 8.3| 2008-02-04 | 8.3.7| 2009-03-16 | 8.2| 2006-12-05 | 8.2.13 | 2009-03-16 | 8.1| 2005-11-08 | 8.1.17 | 2009-03-16 | 8.0| 2005-01-19 | 8.0.21 | 2009-03-16 | 7.4| 2003-11-17 | 7.4.25 | 2009-03-16 | 2009-09-01 (projected) 7.3| 2002-11-27 | 7.3.21 | 2008-01-07 | 2008-01-07 7.2| 2002-02-04 | 7.2.8| 2005-05-09 | 2005-05-09 7.1| 2001-04-13 | 7.1.3| 2001-08-15 | 2001-08-15 7.0| 2000-05-08 | 7.0.3| 2000-11-11 | 2000-11-11 Yeah, nice. I was thinking of a press release when we EOL a branch as well. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
David E. Wheeler wrote: On Jul 7, 2009, at 11:59 AM, Alvaro Herrera wrote: And it only goes back to 8.0 Huh, true :-( This should be fixed. Yeah. Or we should have a table. I could create one in the wiki, I guess, but I would assume that the core team would want to have formal control over scheduled maintenance expirations… The web team already has a table, and it is published as the RSS I linked to. If you want it in another format I think it should be on the main website (not wiki), derived from the table already present. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
On Jul 7, 2009, at 12:59 PM, Alvaro Herrera wrote: Yeah. Or we should have a table. I could create one in the wiki, I guess, but I would assume that the core team would want to have formal control over scheduled maintenance expirations… The web team already has a table, and it is published as the RSS I linked to. If you want it in another format I think it should be on the main website (not wiki), derived from the table already present. That would be great, with a link to it from an appropriate part of the nav. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Maintenance Policy?
Andrew Dunstan wrote: ... branch | released | curr_version | curr_date | final_date ++--++ 8.4| 2009-07-01 | 8.4.0| 2009-07-01 | 8.3| 2008-02-04 | 8.3.7| 2009-03-16 | 8.2| 2006-12-05 | 8.2.13 | 2009-03-16 | 8.1| 2005-11-08 | 8.1.17 | 2009-03-16 | 8.0| 2005-01-19 | 8.0.21 | 2009-03-16 | 7.4| 2003-11-17 | 7.4.25 | 2009-03-16 | 2009-09-01 (projected) 7.3| 2002-11-27 | 7.3.21 | 2008-01-07 | 2008-01-07 7.2| 2002-02-04 | 7.2.8| 2005-05-09 | 2005-05-09 7.1| 2001-04-13 | 7.1.3| 2001-08-15 | 2001-08-15 7.0| 2000-05-08 | 7.0.3| 2000-11-11 | 2000-11-11 Yeah, nice. I was thinking of a press release when we EOL a branch as well. You may want to indicate the dead-end of the 8.1 Windows variant as well. http://www.postgresql.org/download/windows says Only PostgreSQL 8.2 and above are supported on Windows. ... might prevent confusion. Greg Williamson -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Maintenance Policy?
Howdy Hackers, Is there a published maintenance policy somewhere? Something that says for how long the project supports minor releases of PostgreSQL. For example, does 7.4 still get bug fixes and minor releases? If not, how does one know when support for a major version has been dropped? Thanks, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
