Re: Release planning (was: Re: Status report)

From: Rod Taylor <pg(at)rbt(dot)ca>
To: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Lamar Owen <lowen(at)pari(dot)edu>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Release planning (was: Re: Status report)
Date: 2004-07-14 02:06:28
Message-ID: 1089770787.49769.4.camel@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2004-07-13 at 20:49, Marc G. Fournier wrote:
> On Tue, 13 Jul 2004, Tom Lane wrote:
>
> > We could certainly do something along that line if we had a few people
> > willing to be "gatekeepers". We'd have to work harder at making the
> > release generation process open and documented though. Right now there
> > are plenty of steps that only you, Bruce, or Lamar (respectively) know
> > how to do...
>
> I think we could do it if we restricted it to *just* one release back ...
> but I do agree with Peter about ppls motivations for upgrading (bug fixes
> vs new features) ... we'd have to have a 'two branch stable', one would be
> only bug fixes, the other would be bug fixes+feature backpatch ... would
> could get interesting trying to figure out release naming conventions :)

FreeBSD does do this. They tag the bug-fix only branches as being
SECURITY releases, since typically they only contain fixes for security
or reliability related issues.

The 5.2.1 release which followed 5.2.0 was an example of one of the few
releases the Security team has done. They usually just allow users to
use CVSUP to follow the branch.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2004-07-14 02:12:05 Re: Release planning (was: Re: Status report)
Previous Message Bruce Momjian 2004-07-14 01:19:37 Re: serverlog rotation/functions