Re: 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(dot)linnakangas(at)enterprisedb(dot)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(at)pgadmin(dot)org> writes:
> On Tue, Jul 7, 2009 at 8:28 AM, Heikki
> Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)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.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 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(at)agliodbs(dot)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(at)momjian(dot)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(at)agliodbs(dot)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(at)dunslane(dot)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:
> Andrew Dunstan <andrew(at)dunslane(dot)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

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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Josh Berkus <josh(at)agliodbs(dot)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(at)druid(dot)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(at)agliodbs(dot)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(at)turnstep(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)momjian(dot)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(at)agliodbs(dot)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