Обсуждение: Odd release numbers for development versions?

Поиск
Список
Период
Сортировка

Odd release numbers for development versions?

От
"Robert B. Easter"
Дата:
Is PostgreSQL going to start using odd release numbers for development
versions?  This is how the Linux kernel is, and some other projects.

Version.release.revision/build

Like 7.0.x would be the current stable branch. 7.1.x, the current development
branch.  The next stable branch would be 7.2.x.  Within the current even
release stable branch, maybe only do bug fixes.  In the odd dev releases, focus
on new/experiemental.  Both branches could have very frequent *.x
revisions/builds.  I guess you'd have to apply patches to both branches
sometimes, like when a bug is found in 7.0.x, it is patched and the same patch
applied to the 7.1.x if needed.

This way there would be a clear distinction for users what is likely to be good
for production use and what is still unproven.

-- 
Robert B. Easter
reaster@comptechnews.com


Re: Odd release numbers for development versions?

От
Bruce Momjian
Дата:
> Is PostgreSQL going to start using odd release numbers for development
> versions?  This is how the Linux kernel is, and some other projects.
> 
> Version.release.revision/build
> 
> Like 7.0.x would be the current stable branch. 7.1.x, the current development
> branch.  The next stable branch would be 7.2.x.  Within the current even
> release stable branch, maybe only do bug fixes.  In the odd dev releases, focus
> on new/experiemental.  Both branches could have very frequent *.x
> revisions/builds.  I guess you'd have to apply patches to both branches
> sometimes, like when a bug is found in 7.0.x, it is patched and the same patch
> applied to the 7.1.x if needed.
> 
> This way there would be a clear distinction for users what is likely to be good
> for production use and what is still unproven.

No even/odd mess.  Every release is stable.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Odd release numbers for development versions?

От
Tom Lane
Дата:
"Robert B. Easter" <reaster@comptechnews.com> writes:
> Like 7.0.x would be the current stable branch. 7.1.x, the current
> development branch.  The next stable branch would be 7.2.x.  Within
> the current even release stable branch, maybe only do bug fixes.  In
> the odd dev releases, focus on new/experiemental.  Both branches could
> have very frequent *.x revisions/builds.

This has been proposed before, and rejected before.  The key developers
mostly don't believe that the Linux style "release early, release often"
approach is appropriate for the Postgres project.  Few people are
interested in running beta-quality databases, so there's no point in
going to the effort of maintaining two development tracks.
        regards, tom lane


Re: Odd release numbers for development versions?

От
The Hermit Hacker
Дата:
not in this life time ...


On Tue, 6 Jun 2000, Robert B. Easter wrote:

> Is PostgreSQL going to start using odd release numbers for development
> versions?  This is how the Linux kernel is, and some other projects.
> 
> Version.release.revision/build
> 
> Like 7.0.x would be the current stable branch. 7.1.x, the current development
> branch.  The next stable branch would be 7.2.x.  Within the current even
> release stable branch, maybe only do bug fixes.  In the odd dev releases, focus
> on new/experiemental.  Both branches could have very frequent *.x
> revisions/builds.  I guess you'd have to apply patches to both branches
> sometimes, like when a bug is found in 7.0.x, it is patched and the same patch
> applied to the 7.1.x if needed.
> 
> This way there would be a clear distinction for users what is likely to be good
> for production use and what is still unproven.
> 
> -- 
> Robert B. Easter
> reaster@comptechnews.com
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 



Re: Odd release numbers for development versions?

От
Lamar Owen
Дата:
Tom Lane wrote:
> 
> "Robert B. Easter" <reaster@comptechnews.com> writes:
> > Like 7.0.x would be the current stable branch. 7.1.x, the current
> > development branch.  The next stable branch would be 7.2.x.  Within
> > the current even release stable branch, maybe only do bug fixes.  In
> > the odd dev releases, focus on new/experiemental.  Both branches could
> > have very frequent *.x revisions/builds.
> This has been proposed before, and rejected before.  The key developers
> mostly don't believe that the Linux style "release early, release often"
> approach is appropriate for the Postgres project.  Few people are
> interested in running beta-quality databases, so there's no point in
> going to the effort of maintaining two development tracks.

If the Linux kernel used CVS like a reasonable Free Software effort,
then the current odd/even split wouldn't even be necessary.  We use CVS
-- if you want development trees to play with, you fetch the tree by
anon CVS and update as often as you need to.  There is absolutely no
need for a Linux-style release system with CVS.

Don't get me wrong; I like and use Linux.  I just like the PostgreSQL
development model better.

"Release Stable; release when necessary" is all that is needed when the
developers use CVS properly.  You want to be a developer?  Grab the CVS
tree and start hacking.  Patches are readily accepted if they are
acceptable.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: Odd release numbers for development versions?

От
"Robert B. Easter"
Дата:
On Tue, 06 Jun 2000, Lamar Owen wrote:
> Tom Lane wrote:
> > 
> > "Robert B. Easter" <reaster@comptechnews.com> writes:
> > > Like 7.0.x would be the current stable branch. 7.1.x, the current
> > > development branch.  The next stable branch would be 7.2.x.  Within
> > > the current even release stable branch, maybe only do bug fixes.  In
> > > the odd dev releases, focus on new/experiemental.  Both branches could
> > > have very frequent *.x revisions/builds.
>  
> > This has been proposed before, and rejected before.  The key developers
> > mostly don't believe that the Linux style "release early, release often"
> > approach is appropriate for the Postgres project.  Few people are
> > interested in running beta-quality databases, so there's no point in
> > going to the effort of maintaining two development tracks.

Ok.  If the key developers feel its not a good idea for this project, I can
accept that.  Just suggested it since now would have been an opportune time to
start that numbering scheme.

> "Release Stable; release when necessary" is all that is needed when the
> developers use CVS properly.  You want to be a developer?  Grab the CVS
> tree and start hacking.  Patches are readily accepted if they are
> acceptable.

Thanks for the invitation.  I'd like contributing something back to this
project someday.

> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
-- 
Robert B. Easter
reaster@comptechnews.com


Re: Odd release numbers for development versions?

От
Tom Lane
Дата:
Lamar Owen <lamar.owen@wgcr.org> writes:
> If the Linux kernel used CVS like a reasonable Free Software effort,
> then the current odd/even split wouldn't even be necessary.  We use CVS
> -- if you want development trees to play with, you fetch the tree by
> anon CVS and update as often as you need to.  There is absolutely no
> need for a Linux-style release system with CVS.

Actually, another way to look at it is that we do have two release
tracks.  There is the bleeding edge (CVS sources, or the nightly
snapshot if you don't want to be bothered with setting up CVS), and
there is the prior stable release (RELm_n CVS branch, which we update
with critical patches and re-release as needed).  Seems like the main
practical difference from the Linux release model is that we don't
bother to make formal labeled/numbered tarballs of the development track
until we are in beta-test cycle.  You want development track at other
times, you just grab the latest sources.

So far, the alternating development and betatest/bugfix cycle has worked
really well for the needs of the Postgres project, so I don't think
anyone is eager to change that approach.
        regards, tom lane


Re: Odd release numbers for development versions?

От
Lamar Owen
Дата:
On Tue, 06 Jun 2000, Robert B. Easter wrote:
> On Tue, 06 Jun 2000, Lamar Owen wrote:

> > "Release Stable; release when necessary" is all that is needed when the
> > developers use CVS properly.  You want to be a developer?  Grab the CVS
> > tree and start hacking.  Patches are readily accepted if they are
> > acceptable.
> Thanks for the invitation.  I'd like contributing something back to this
> project someday.

I'm sure that you could find something in our TODO list to meet your fancy...
:-)

My response wasn't intended as a flame; although, in hindsight, I see I was
harsher than I meant to be. Sorry 'bout that.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: Odd release numbers for development versions?

От
Lamar Owen
Дата:
On Tue, 06 Jun 2000, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > anon CVS and update as often as you need to.  There is absolutely no
> > need for a Linux-style release system with CVS.
> Seems like the main
> practical difference from the Linux release model is that we don't
> bother to make formal labeled/numbered tarballs of the development track
> until we are in beta-test cycle.  You want development track at other
> times, you just grab the latest sources.
> So far, the alternating development and betatest/bugfix cycle has worked
> really well for the needs of the Postgres project, so I don't think
> anyone is eager to change that approach.

With our use of CVS, there is no need for the split release, IOW.  We have a
similar, yet more open system here -- one I rather like.  Of course, if you
just read the website, you don't get that feeling -- it takes a year or so on
the list to really understand what this group is all about.  (No criticism
intended of the website, Vince -- it does its job nicely).

For the first two years of my use of PostgreSQL, the only information I had was
on the website -- boy, was I in for a pleasant surprise when I subscribed to
this list!

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11