Thread: 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
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
On Tue, Jul 7, 2009 at 8:28 AM, Heikki Linnakangas<heikki.linnakangas@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
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
Dave Page <dpage@pgadmin.org> writes:
> On Tue, Jul 7, 2009 at 8:28 AM, Heikki
> Linnakangas<heikki.linnakangas@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
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
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
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
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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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
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.rssHTTP/1.1 200 OKDate: Tue, 07 Jul 2009 18:56:48 GMTServer: ApacheLast-Modified:Wed, 01 Jul 2009 11:25:40 GMTETag: "bd2589-a8d-46da32eda5500"Accept-Ranges: bytesContent-Length: 2701Connection:closeContent-Type: application/rss+xml I guess it depends on the mirror. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
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
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
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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
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
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
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
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
Josh Berkus <josh@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
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Jul 10, 2009, at 6:01 PM, Josh Berkus <josh@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
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
Andrew Dunstan <andrew@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
Tom Lane wrote: <blockquote cite="mid:3404.1247272796@sss.pgh.pa.us" type="cite"><pre wrap="">Andrew Dunstan <a class="moz-txt-link-rfc2396E"href="mailto:andrew@dunslane.net"><andrew@dunslane.net></a> writes: </pre><blockquotetype="cite"><pre wrap="">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. </pre></blockquote><pre wrap=""> 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. </pre></blockquote> Would it be reasonable to have the "squishy intention" coupled with a more firm policyof "...EOL will be announced X months in advance...Users requiring firm long-term EOL commitments are advised to purchasecommercial support..."<br /><br /> Perhaps the postgresql.org home-page should be modified slightly. Instead of "LatestReleases" (which doesn't even list 7.4 when I just looked), it could be something like "Current Releases". Then whenEOL is announced, the release could be suffixed with the EOL date (i.e. 7.4.25 EOL 2009-12-31 - maybe even with the EOLdate in bold and/or red) which would link to the EOL announcement or general EOL statement page.<br /><br /> I think thata "EOL Statement" link to a page with the generic statement placed just below the oldest release could be helpful aswell.<br /><br /> Cheers,<br /> Steve<br /><br />
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
On Fri, 10 Jul 2009 19:51:31 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Josh Berkus <josh@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 <darcy@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.
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
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
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?
> 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
On Sun, Jul 12, 2009 at 11:53 PM, Josh Berkus<josh@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
-----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 greg@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-----
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Mon, Jul 13, 2009 at 2:07 AM, Bruce Momjian<bruce@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
Greg Stark wrote: > On Mon, Jul 13, 2009 at 2:07 AM, Bruce Momjian<bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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
Josh Berkus <josh@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