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, Pennsylvania 19026
"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