Thread: end of life for pg versions...
I did manage to find an announcement about the support of pg for windows... but I wasn't able to see anything you'd have a summary of scheduled and planned EOL for various pg versions (on different platform). -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Feb 11, 2008 8:04 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote: > I did manage to find an announcement about the support of pg for > windows... but I wasn't able to see anything you'd have a summary of > scheduled and planned EOL for various pg versions (on different > platform). There have been some secondary sources for support that simultaneously promise longer support times than PGDG does... For instance, support for 7.3 has essentially ceased, but Red Hat has that included in some version(s) of their distributions that still have some time to run before they fall out of RHAT support. So if issues come up with 7.3, they *may* be indirectly addressed thru someone like RHAT. Similarly, Sun or EnterpriseDB may make support promises that exceed what PGDG offers. What you'll find, in practice, is that if you have issues with old versions, and report such, people will be quick to recommend upgrading to some version that is less ancient. Nothing has crystallized into a "real policy;" if someone feels like backpatching bug fixes back to 7.1, nothing is stopping them from doing so. But that takes more time and effort, so the eldest version that is now still getting patched is 7.4. And it is pretty plausible that that may change to 8.0 in the next year or so. -- http://linuxfinances.info/info/linuxdistributions.html "The definition of insanity is doing the same thing over and over and expecting different results." -- assortedly attributed to Albert Einstein, Benjamin Franklin, Rita Mae Brown, and Rudyard Kipling
On Mon, Feb 11, 2008 at 08:46:00AM -0500, Christopher Browne wrote: > On Feb 11, 2008 8:04 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote: > > I did manage to find an announcement about the support of pg for > > windows... but I wasn't able to see anything you'd have a summary of > > scheduled and planned EOL for various pg versions (on different > > platform). > > There have been some secondary sources for support that simultaneously > promise longer support times than PGDG does... > > For instance, support for 7.3 has essentially ceased, but Red Hat has > that included in some version(s) of their distributions that still > have some time to run before they fall out of RHAT support. So if > issues come up with 7.3, they *may* be indirectly addressed thru > someone like RHAT. > > Similarly, Sun or EnterpriseDB may make support promises that exceed > what PGDG offers. > > What you'll find, in practice, is that if you have issues with old > versions, and report such, people will be quick to recommend upgrading > to some version that is less ancient. > > Nothing has crystallized into a "real policy;" if someone feels like > backpatching bug fixes back to 7.1, nothing is stopping them from > doing so. But that takes more time and effort, so the eldest version > that is now still getting patched is 7.4. And it is pretty plausible > that that may change to 8.0 in the next year or so. Please note that the only documented versioning oplicy we do have says security fixes are only backpatched to 7.4 and later. And this change was made as we released 7.3.21 early january. //Magnus
On Mon, 11 Feb 2008 08:46:00 -0500 "Christopher Browne" <cbbrowne@gmail.com> wrote: > On Feb 11, 2008 8:04 AM, Ivan Sergio Borgonovo > <mail@webthatworks.it> wrote: > > I did manage to find an announcement about the support of pg for > > windows... but I wasn't able to see anything you'd have a summary > > of scheduled and planned EOL for various pg versions (on different > > platform). > > There have been some secondary sources for support that > simultaneously promise longer support times than PGDG does... What about a place where to read announcement made by the PostgreSQL Global Development Team? I can't think of going more upstream than them. thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Mon, Feb 11, 2008 at 03:26:39PM +0100, Ivan Sergio Borgonovo wrote: > On Mon, 11 Feb 2008 08:46:00 -0500 > "Christopher Browne" <cbbrowne@gmail.com> wrote: > > > On Feb 11, 2008 8:04 AM, Ivan Sergio Borgonovo > > <mail@webthatworks.it> wrote: > > > I did manage to find an announcement about the support of pg for > > > windows... but I wasn't able to see anything you'd have a summary > > > of scheduled and planned EOL for various pg versions (on different > > > platform). > > > > There have been some secondary sources for support that > > simultaneously promise longer support times than PGDG does... > > > What about a place where to read announcement made by the PostgreSQL > Global Development Team? > I can't think of going more upstream than them. http://www.postgresql.org/support/security that's probably the best one you can find. Or that in combination with the news archive (http://www.postgresql.org/about/newsarchive) //Magnus
On Mon, 11 Feb 2008 15:36:21 +0100 Magnus Hagander <magnus@hagander.net> wrote: > http://www.postgresql.org/support/security > > that's probably the best one you can find. Or that in combination > with the news archive (http://www.postgresql.org/about/newsarchive) Really... without making it too formal as a developer I'd appreciate a rough schedule a page where you would say something like: - we expect our next minor release will come out in X months - we expect our major release will come out in Y months - EOL of release A for platform B is planned around date Z Even with a disclaimer with a very bland commitment to the release schedule it could help developers to build up their own schedule and support list too and give some hook for advocacy as well. thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Feb 11, 2008, at 9:33 AM, Ivan Sergio Borgonovo wrote: > On Mon, 11 Feb 2008 15:36:21 +0100 > Magnus Hagander <magnus@hagander.net> wrote: >> http://www.postgresql.org/support/security >> >> that's probably the best one you can find. Or that in combination >> with the news archive (http://www.postgresql.org/about/newsarchive) > > Really... without making it too formal as a developer I'd appreciate > a rough schedule a page where you would say something like: > > - we expect our next minor release will come out in X months > - we expect our major release will come out in Y months > - EOL of release A for platform B is planned around date Z > > Even with a disclaimer with a very bland commitment to the release > schedule it could help developers to build up their own schedule and > support list too and give some hook for advocacy as well. The problem with that is that as a volunteer-run project, dates can be off by a mile. Less than a year ago the plan was to release 8.3 is August-September 2007. Instead it was released a week or two ago. IIRC, the decision to end support for a version is determined in large part by how hard it would be to back-patch something. If a bug was found that dated back to 7.4 but was very difficult to fix in 7.4 I bet you'd see 7.4 get EOL'd unless someone wanted to pay to back- patch it. I think the closest thing to a policy you'll find is a discussion from a year or two ago where the consensus was that we should endeavor to support a version for at least 2 years after it's replacement comes out (ie: 8.2 should be supported for at least 2 years after we released 8.3). -- Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828
Attachment
On Mon, 11 Feb 2008 17:53:06 -0600 Decibel! <decibel@decibel.org> wrote: > The problem with that is that as a volunteer-run project, dates > can be off by a mile. Less than a year ago the plan was to release > 8.3 is August-September 2007. Instead it was released a week or two > ago. That's why I wrote "without making it too formal" and "bland commitment to the release schedule...". Just a place where you could have some idea without digging into the lists or announcement. Not everyone has the same level of involvement to know what's happening among the developers. Not only it will help developer but will help advocacy too. > I think the closest thing to a policy you'll find is a discussion > from a year or two ago where the consensus was that we should > endeavor to support a version for at least 2 years after it's > replacement comes out (ie: 8.2 should be supported for at least 2 > years after we released 8.3). This kind of statement are hard to find out. As said even if it was a very bland schedule there should be a place where people can see easily when next version is expected, when generally version reach EOL. If you spice it up with planned features it would even be better. Many people aren't used to pg "culture" and "community" and "oral knowledge" of postgresql. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Tue, Feb 12, 2008 at 09:44:30AM +0100, Ivan Sergio Borgonovo wrote: > > That's why I wrote "without making it too formal" and "bland > commitment to the release schedule...". The problem with doing it that way is that, when the release fails to meet the original target deadline, any coverage of a new release will inevitably include notes remarks about how the release was "six months late" or whatever. The computer press is driven mostly by commercial firms, who have to have software schedules because that's how they pay their bills. A
On Tue, 12 Feb 2008 11:19:19 -0500 Andrew Sullivan <ajs@crankycanuck.ca> wrote: > On Tue, Feb 12, 2008 at 09:44:30AM +0100, Ivan Sergio Borgonovo > wrote: > > That's why I wrote "without making it too formal" and "bland > > commitment to the release schedule...". > The problem with doing it that way is that, when the release fails > to meet the original target deadline, any coverage of a new release > will inevitably include notes remarks about how the release was > "six months late" or whatever. The computer press is driven mostly So? Comparably you've more commitment with your user base than with the press. I think the user base will appreciate to have a rough idea without resorting into digging into 3 months old announcement or what else. > by commercial firms, who have to have software schedules because > that's how they pay their bills. If you're so concerned about journalists (and concurrences) what do you think will stop them about writing pg doesn't have a clear schedule bla bla bla...? A lot of people are betting on the advancement and feature additions of the unnamed concurrence for example... and claiming there won't be any reason to use pg shortly... since the unnamed concurrence is catching up. Is it just vaporware... maybe... but still there are pros and cons of having a bland schedule for EOL and new releases. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Ivan Sergio Borgonovo wrote: > Is it just vaporware... maybe... but still there are pros and cons of > having a bland schedule for EOL and new releases. We do have a schedule: http://developer.postgresql.org/index.php/PostgreSQL_8.4_Development_Plan -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Tue, 12 Feb 2008 16:15:23 -0300 Alvaro Herrera <alvherre@commandprompt.com> wrote: > Ivan Sergio Borgonovo wrote: > > > Is it just vaporware... maybe... but still there are pros and > > cons of having a bland schedule for EOL and new releases. > > We do have a schedule: > http://developer.postgresql.org/index.php/PostgreSQL_8.4_Development_Plan woops maybe what's missing is a clear link on the main site[1] + EOL. thanks [1] http://www.postgresql.org/ I'd place it in the support menu... -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Tuesday 12 February 2008 15:48, Ivan Sergio Borgonovo wrote: > On Tue, 12 Feb 2008 16:15:23 -0300 > > Alvaro Herrera <alvherre@commandprompt.com> wrote: > > Ivan Sergio Borgonovo wrote: > > > Is it just vaporware... maybe... but still there are pros and > > > cons of having a bland schedule for EOL and new releases. > > > > We do have a schedule: > > http://developer.postgresql.org/index.php/PostgreSQL_8.4_Development_Plan > > woops maybe what's missing is a clear link on the main site[1] + EOL. > > thanks > > [1] http://www.postgresql.org/ I'd place it in the support menu... Actually I think we should be pointing people to http://www.postgresql.org/developer/roadmap. Of course we would still need to add an EOL page... I think one could make a strong argument for a static url for EOL info now that windows is EOL for < 8.2. -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Ivan Sergio Borgonovo wrote: > On Tue, 12 Feb 2008 16:15:23 -0300 > Alvaro Herrera <alvherre@commandprompt.com> wrote: > > > Ivan Sergio Borgonovo wrote: > > > > > Is it just vaporware... maybe... but still there are pros and > > > cons of having a bland schedule for EOL and new releases. > > > > We do have a schedule: > > http://developer.postgresql.org/index.php/PostgreSQL_8.4_Development_Plan > > woops maybe what's missing is a clear link on the main site[1] + EOL. I don't think that information belongs into the main page -- it's for developers only. The "roadmap" page linked to by Robert is for general consumption. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Robert Treat <xzilla@users.sourceforge.net> writes:
> Of course we would still need to add an EOL page... I think one could make a
> strong argument for a static url for EOL info now that windows is EOL for <
> 8.2.
You could make a strong argument for a page stating that versions
thus-and-so are *already* EOL'd. What the OP seems to be insisting
is that we produce a formal policy and timetable for future EOL
decisions, neither of which seem very likely or desirable to me.
regards, tom lane
Tom Lane wrote: > Robert Treat <xzilla@users.sourceforge.net> writes: > > Of course we would still need to add an EOL page... I think one could make a > > strong argument for a static url for EOL info now that windows is EOL for < > > 8.2. > > You could make a strong argument for a page stating that versions > thus-and-so are *already* EOL'd. What the OP seems to be insisting > is that we produce a formal policy and timetable for future EOL > decisions, neither of which seem very likely or desirable to me. We could record the dates we made versions EOL and they can interpolate from there. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Tue, 12 Feb 2008 17:13:15 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Treat <xzilla@users.sourceforge.net> writes: > > Of course we would still need to add an EOL page... I think one > > could make a strong argument for a static url for EOL info now > > that windows is EOL for < 8.2. > > You could make a strong argument for a page stating that versions > thus-and-so are *already* EOL'd. What the OP seems to be insisting > is that we produce a formal policy and timetable for future EOL > decisions, neither of which seem very likely or desirable to me. Not formal... just some general guideline to guess when to expect a EOL and a new release and new features. I think putting this kind of thing in a more prominent place on the main web site will help developers and advocacy too. It could be even an informal speech that explain how it works so people will be able to take their measures. Some pointers and some general guideline passed just on the list: expected feature, general rules about when to expect a version will be put in EOL (2 years or when it is too hard to backport bug fixes) etc... These information are somehow part of "oral tradition", I think that as much as they may seem informal they still deserve a more prominent place and a less spread distribution. -- Ivan Sergio Borgonovo http://www.webthatworks.it