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

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.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&gt; 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. +