SEO

By chance I happened to notice in the release notes

Release 7.3
Release date: 2002-11-27

Man, it feels like a long time since that came out...

There has been some discussion of making a project policy of dropping
support for old releases after five years. Should we consider formally
instituting that?

I see that there are two or three minor bug fixes in the REL7_3_STABLE
branch since 7.3.20. Rather than just leaving those to rot, maybe the
actual policy should be "only one more update after 8.3 comes out".

Comments, opinions?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Tue, 2007-11-27 at 14:02 -0500, Tom Lane wrote:
> By chance I happened to notice in the release notes
>
> Release 7.3
> Release date: 2002-11-27
>
> Man, it feels like a long time since that came out...
>
> There has been some discussion of making a project policy of dropping
> support for old releases after five years. Should we consider formally
> instituting that?
>
> I see that there are two or three minor bug fixes in the REL7_3_STABLE
> branch since 7.3.20. Rather than just leaving those to rot, maybe the
> actual policy should be "only one more update after 8.3 comes out".
>
> Comments, opinions?

At some point back, I seem to recall the reason for bothering to
backpatch to 7.3 is that it had to be maintained for RedHat anyway, so
things might as well be backpatched? If that requirements is gone, I
think it's time to drop it.

And +1 on pushing out one final "end of the tree" release since there's
stuff there.

//Magnus


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

> At some point back, I seem to recall the reason for bothering
> to backpatch to 7.3 is that it had to be maintained for
> RedHat anyway, so things might as well be backpatched? If
> that requirements is gone, I think it's time to drop it.

+1

> And +1 on pushing out one final "end of the tree" release
> since there's stuff there.
>

+1


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Tue, 27 Nov 2007 11:08:58 -0800 Joshua D. Drake wrote:

> Release 7.3.21 with and EOL addendum . E.g; this is the last release
> of 7.3 and 7.3 is now considered unsupported.

I know at least one customer who is using RHEL-3 and PG 7.3 on dozens
machines worldwide. Yes, they are moving to 8.2 but this will require
some more month and eventually not all machines can just be updated to
a newer OS/DB version.

So i'm also for stopping support for 7.3 but not the way you proposed.
If we have supported 7.3 up to now, there should be an official notice
with a date, when support ends. This date should not be the next and
final release some days after the notice ;-)


Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Tue, 2007-11-27 at 14:02 -0500, Tom Lane wrote:

> There has been some discussion of making a project policy of dropping
> support for old releases after five years. Should we consider formally
> instituting that?
>
> I see that there are two or three minor bug fixes in the REL7_3_STABLE
> branch since 7.3.20. Rather than just leaving those to rot, maybe the
> actual policy should be "only one more update after 8.3 comes out".

Well, I agree that it shouldn't be your responsibility to do that. We
need to reduce the things you have to worry about to allow you to focus
on later releases.

One of the good things about open source is the ability for software to
remain supported for many years longer than closed source software.

Perhaps we should ask for volunteers to maintain that branch? If we had
a maintenance release manager, then they can take responsibility for
passing down any appropriate bug fixes. We could also create a new list
for people discussing older releases, so we don't get pinged all the
time.

That way anybody with an application at older release levels can either
step up to the plate or lose support.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Tom,

> There has been some discussion of making a project policy of dropping
> support for old releases after five years. Should we consider formally
> instituting that?

The community consensus I recall was three versions only. Anything beyond
that would be up to the vendors.

Mind you, I don't know what EDB guarentees but the Sun folks could end up
patching everything back to 8.1 for the next 5 years depending on customer
demand. So I think 5 years will be a reality for us for the conceivable
future.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Josh Berkus <josh@agliodbs.com> writes:
>> There has been some discussion of making a project policy of dropping
>> support for old releases after five years. Should we consider formally
>> instituting that?

> The community consensus I recall was three versions only. Anything beyond
> that would be up to the vendors.

Yeah, but some of us are also the vendors ;-). I still figure that if
I have to maintain branch X for Red Hat, I might as well put those fixes
in the community CVS. I should think that Sun, EDB, et al would also
find it expedient to not need to maintain private patch sets. So it
seems to me that the "vendor" EOL horizons are legitimate to consider
while deciding what the "community" wants to support.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

"Andreas 'ads' Scherbaum" <adsmail@wars-nicht.de> writes:
> On Tue, 27 Nov 2007 11:08:58 -0800 Joshua D. Drake wrote:
>> Release 7.3.21 with and EOL addendum . E.g; this is the last release
>> of 7.3 and 7.3 is now considered unsupported.

> I know at least one customer who is using RHEL-3 and PG 7.3 on dozens
> machines worldwide.

Are they running 7.3.20? Will they update to 7.3.21 promptly when we
ship it? Or are they using whatever Red Hat includes in RHEL-3?
(which is still 7.3.19 I believe)

One of the reasons for losing interest in frequent updates is that
it seems most of the people we hear from who are running 7.3.x are
running a pretty obsolete "x". If we produce an update and no one
actually installs it, we're just wasting time with make-work.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Josh Berkus wrote:
> Tom,
>
>
>> There has been some discussion of making a project policy of dropping
>> support for old releases after five years. Should we consider formally
>> instituting that?
>>
>
> The community consensus I recall was three versions only. Anything beyond
> that would be up to the vendors.
>
> Mind you, I don't know what EDB guarentees but the Sun folks could end up
> patching everything back to 8.1 for the next 5 years depending on customer
> demand. So I think 5 years will be a reality for us for the conceivable
> future.
>
>

I don't know that we came up with a highly specific policy. My
recollection was something like "Support would be maintained for n years
(or possibly releases), after which we could discontinue support at any
time if bugs were unpatchable."

The burden of maintaining back releases isn't really all that great, ISTM.

I have no objection to cutting a release and declaring it final (with a
possible exception for security fixes).

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Tuesday 27 November 2007 15:07, Simon Riggs wrote:
> On Tue, 2007-11-27 at 14:02 -0500, Tom Lane wrote:
> > There has been some discussion of making a project policy of dropping
> > support for old releases after five years. Should we consider formally
> > instituting that?
> >
> > I see that there are two or three minor bug fixes in the REL7_3_STABLE
> > branch since 7.3.20. Rather than just leaving those to rot, maybe the
> > actual policy should be "only one more update after 8.3 comes out".
>
> Well, I agree that it shouldn't be your responsibility to do that. We
> need to reduce the things you have to worry about to allow you to focus
> on later releases.
>
> One of the good things about open source is the ability for software to
> remain supported for many years longer than closed source software.
>
> Perhaps we should ask for volunteers to maintain that branch? If we had
> a maintenance release manager, then they can take responsibility for
> passing down any appropriate bug fixes. We could also create a new list
> for people discussing older releases, so we don't get pinged all the
> time.
>
> That way anybody with an application at older release levels can either
> step up to the plate or lose support.

+1 to see if anyone else wants to take over management of the branch. I also
think we should be a bit more generous on the EOL notice. Saying one more
update after 8.3 is akin to giving a 1 month EOL notice; not friendly at all
imo. Set it for July 2008 and I think you have given plenty of notice (and
given the lack of back patches, should be too much of a burden in that time
either)

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate