Thread: Odd release numbers for development versions?
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
> 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
"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
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
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
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
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
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
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