Release cycle length
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that. We already have a number of significant
improvements in 7.5 now, and several good ones coming up in the next few
weeks. We cannot let people wait 1 year for that. I suggest that we aim
for a 6 month cycle, consisting of approximately 4 months of development
and 2 months of cleanup. So the start of the next beta could be the 1st
of March. What do you think?
--
Peter Eisentraut peter_e@gmx.net
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that. We already have a number of significant
improvements in 7.5 now, and several good ones coming up in the next few
weeks. We cannot let people wait 1 year for that. I suggest that we aim
for a 6 month cycle, consisting of approximately 4 months of development
and 2 months of cleanup. So the start of the next beta could be the 1st
of March. What do you think?
That is the usual goal *nod* Same goal we try for each release, and never
quite seem to get there ... we'll try 'yet again' with v7.5 though, as we
always do :)
Marc G. Fournier writes:
That is the usual goal *nod* Same goal we try for each release, and never
quite seem to get there ... we'll try 'yet again' with 7.5 though, as we
always do :)
I don't see how we could have tried for a 4-month development period and
ended up with an 8-month period. Something went *really* wrong there.
Part of that may have been that few people were actually aware of that
schedule.
--
Peter Eisentraut peter_e@gmx.net
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
Marc G. Fournier writes:
That is the usual goal *nod* Same goal we try for each release, and never
quite seem to get there ... we'll try 'yet again' with 7.5 though, as we
always do :)I don't see how we could have tried for a 4-month development period and
ended up with an 8-month period. Something went *really* wrong there.
Part of that may have been that few people were actually aware of that
schedule.
Everyone on -hackers should have been aware of it, as its always
discussed at the end of the previous release cycle ... and I don't think
we've hit a release cycle yet that has actually stayed in the 4 month
period :( Someone is always 'just sitting on something that is almost
done' at the end that pushes it further then originally planned ...
Just did a quick search on archives, and the original plan was for a
release in mid-2003, which means the beta would have been *at least* a
month before that, so beta starting around May:
http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php
On Mon, 17 Nov 2003, Marc G. Fournier wrote:
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
Marc G. Fournier writes:
That is the usual goal *nod* Same goal we try for each release, and never
quite seem to get there ... we'll try 'yet again' with 7.5 though, as we
always do :)I don't see how we could have tried for a 4-month development period and
ended up with an 8-month period. Something went *really* wrong there.
Part of that may have been that few people were actually aware of that
schedule.Everyone on -hackers should have been aware of it, as its always
discussed at the end of the previous release cycle ... and I don't think
we've hit a release cycle yet that has actually stayed in the 4 month
period :( Someone is always 'just sitting on something that is almost
done' at the end that pushes it further then originally planned ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Peter Eisentraut <peter_e@gmx.net> writes:
The time from release 7.3 to release 7.4 was 355 days, an all-time
high. We really need to shorten that.
Why is that?
-Neil
Marc G. Fournier writes:
Just did a quick search on archives, and the original plan was for a
release in mid-2003, which means the beta would have been *at least* a
month before that, so beta starting around May:http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php
That was a Bruce Momjian estimate mentioned in passing, not an affirmed
plan. Also, I think Bruce's estimates are notoriously off by years. ;-)
--
Peter Eisentraut peter_e@gmx.net
Neil Conway writes:
Peter Eisentraut <peter_e@gmx.net> writes:
The time from release 7.3 to release 7.4 was 355 days, an all-time
high. We really need to shorten that.Why is that?
First, if you develop something today, the first time users would
realistically get a hand at it would be January 2005. Do you want that?
Don't you want people to use your code? We fix problems, but people must
wait a year for the fix?
Second, the longer a release cycle, the more problems amass. People just
forget what they were doing in the beginning, no one is around to fix the
problems introduced earlier, no one remembers anything when it comes time
to write release notes. The longer you develop, the more parallel efforts
are underway, and it becomes impossible to synchronize them to a release
date. People are not encouraged to provide small, well-thought-out,
modular improvements. Instead, they break everything open and worry about
it later. At the end, it's always a rush to close these holes.
Altogether, it's a loss for both developers and users.
--
Peter Eisentraut peter_e@gmx.net
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that. We already have a number of significant
improvements in 7.5 now, and several good ones coming up in the next few
weeks. We cannot let people wait 1 year for that. I suggest that we aim
for a 6 month cycle, consisting of approximately 4 months of development
and 2 months of cleanup. So the start of the next beta could be the 1st
of March. What do you think?
So long as pg_dump object ordering is an early fix to make upgrades
rather more painless, I'm all for it :)
Does anyone have a comparison of how many lines of code were added in
this release compared to previous?
Chris
Everyone on -hackers should have been aware of it, as its always
discussed at the end of the previous release cycle ... and I don't think
we've hit a release cycle yet that has actually stayed in the 4 month
period :( Someone is always 'just sitting on something that is almost
done' at the end that pushes it further then originally planned ...
I think that the core just need to be tough on it, that's all.
If we have pre-published target dates, then everyone knows if they can
get their code in or not for that date.
Chris
Hello,
Personally I am for long release cycles, at least for major releases.
In fact
as of 7.4 I think there should possibly be a slow down in releases with more
incremental releases (minor releases) throughout the year.
People are running their companies and lives off of PostgreSQL, they
should
be able to rely on a specific feature set, and support from the community
for longer.
Sincerely,
Joshua Drake
Peter Eisentraut wrote:
Neil Conway writes:
Peter Eisentraut <peter_e@gmx.net> writes:
The time from release 7.3 to release 7.4 was 355 days, an all-time
high. We really need to shorten that.Why is that?
First, if you develop something today, the first time users would
realistically get a hand at it would be January 2005. Do you want that?
Don't you want people to use your code? We fix problems, but people must
wait a year for the fix?Second, the longer a release cycle, the more problems amass. People just
forget what they were doing in the beginning, no one is around to fix the
problems introduced earlier, no one remembers anything when it comes time
to write release notes. The longer you develop, the more parallel efforts
are underway, and it becomes impossible to synchronize them to a release
date. People are not encouraged to provide small, well-thought-out,
modular improvements. Instead, they break everything open and worry about
it later. At the end, it's always a rush to close these holes.Altogether, it's a loss for both developers and users.
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.orgOn Tue, 18 Nov 2003, Christopher Kings-Lynne wrote:
Everyone on -hackers should have been aware of it, as its always
discussed at the end of the previous release cycle ... and I don't think
we've hit a release cycle yet that has actually stayed in the 4 month
period :( Someone is always 'just sitting on something that is almost
done' at the end that pushes it further then originally planned ...I think that the core just need to be tough on it, that's all.
If we have pre-published target dates, then everyone knows if they can
get their code in or not for that date.
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...
April 1st, or 4 mos from last release, tends to be what we aim for with
all releases ... as everyone knows, we don't necessarily acheive it, but
...
Actually, historically, it looks like we've always been close to 12 months
between releases ... 7.0->7.1: ~11mos, 7.1->7.2: ~10mos, 7.2->7.3: ~9 mos,
and 7.3->7.4: ~12mos ... so, on average, we're dealing with an ~10mos
release cycle for the past 3 years ...
svr1# ls -l */postgresql-7.?.tar.gz
-rw-rw-r-- 1 pgsql pgsql 9173732 May 9 2000 v7.0/postgresql-7.0.tar.gz
-rw-r--r-- 1 pgsql pgsql 8088678 Apr 13 2001 v7.1/postgresql-7.1.tar.gz
-rw-r--r-- 1 pgsql pgsql 9180168 Feb 4 2002 v7.2/postgresql-7.2.tar.gz
-rw-r--r-- 1 pgsql pgsql 11059455 Nov 27 2002 v7.3/postgresql-7.3.tar.gz
-rw-r--r-- 1 pgsql pgsql 12311256 Nov 16 17:57 v7.4/postgresql-7.4.tar.gz
"Joshua D. Drake" <jd@commandprompt.com> writes:
Hello,
Personally I am for long release cycles, at least for major releases.
In fact
as of 7.4 I think there should possibly be a slow down in releases with more
incremental releases (minor releases) throughout the year.
That would pretty much mean changing the "minor releases only for
serious bugfixes" philosphy. Is that what you are advocating?
People are running their companies and lives off of PostgreSQL,
they should be able to rely on a specific feature set, and support
from the community for longer.
If 7.3.4 works for you, there's nothing to stop you running it until
the end of time... If you can't patch in bugfixes yourself, you
should be willing to pay for support. Commercial companies like Red
Hat don't support their releases indefinitely for free; why should the
PG community be obligated to?
Also, we very rarely remove features--AUTOCOMMIT on the server is
about the only one I can think of.
-Doug
Import Notes
Reply to msg id not found: JoshuaD.DrakesmessageofMon17Nov2003175820-0800
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...April 1st, or 4 mos from last release, tends to be what we aim for with
all releases ... as everyone knows, we don't necessarily acheive it, but
Make it April 2nd, otherwise everyone will think it's a joke :P
Chris
Marc G. Fournier writes:
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...
OK, here start the problems. Development already started, so April 1st is
already 5 months development. Add 1 month because no one is willing to
hold people to these dates. So that's 6 months. Then for 6 months of
development, you need at least 2 months of beta. So we're already in the
middle of July, everyone is on vacation, and we'll easily reach the 9
months -- instead of 6.
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
First, if you develop something today, the first time users would
realistically get a hand at it would be January 2005. Do you want
that? Don't you want people to use your code?
Sure :-) But I don't mind a long release cycle if it is better for
users.
We fix problems, but people must wait a year for the fix?
A couple points:
(a) Critical problems can of course be fixed via point releases in
the current stable release series
(b) As PostgreSQL gets more mature, the number of absolutely show
stopping features or bug fixes in a new release gets
smaller. For example, I'd argue that neither 7.3 or 7.4 include
a single feature that is as important as 7.2's lazy VACUUM or
7.1's WAL. There are lots of great features, but the set of
absolutely essential new features tends to grow smaller over
time. I'd wager that for the vast majority of our user base,
PostgreSQL already works well.
(c) As PostgreSQL gets more mature, putting out stable,
production-worthy releases becomes even more important. In
theory, longer release cycles contribute to higher quality
releases: we have more time to implement new features properly,
polish rough edges and document things, test and find bugs, and
ensure that features we've implemented earlier in the release
cycle are properly thought out, and so forth.
Note that whether or not we are using those 355 days effectively
is another story -- it may well be true that there are we could
make parts of the development process much more efficient.
Furthermore, longer release cycles reduce, to some degree, the pain of
upgrades. Unless we make substantial improvements to the upgrade story
any time soon, I wouldn't be surprised if many DBAs are relieved at
only needing to upgrade once a year.
The longer you develop, the more parallel efforts are underway, and
it becomes impossible to synchronize them to a release date.
I think this is inherent to the way PostgreSQL is developed: Tom has
previously compared PostgreSQL release scheduling to herding cats :-)
As long as much of the work on the project is done by volunteers in
their spare time, ISTM that coordinating everyone toward a single
release date is going to be difficult, if not impossible. The length
of the release cycle doesn't really effect this, IMHO.
People are not encouraged to provide small, well-thought-out,
modular improvements.
I agree we can always do better when it comes to code quality. I think
the NetBSD team puts it well:
Some systems seem to have the philosophy of "If it works, it's
right". In that light NetBSD could be described as "It doesn't
work /unless/ it's right".
That said, I don't see how this is related to the release schedule. In
fact, one could argue that a longer release schedule gives new
features a longer "gestation period" during which developers can
ensure that they are well-thought out and implemented properly.
Altogether, it's a loss for both developers and users.
I don't think it's nearly as clear-cut as that. Both types of release
scheduling have their benefits and their drawbacks. My main point is
really that a short release cycle is not an unqualified good (not to
mention that in the past we've been completely unable to actually
*execute* a short release cycle, making this whole discussion a little
academic).
-Neil
Peter Eisentraut wrote:
Marc G. Fournier writes:
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...OK, here start the problems. Development already started, so April 1st is
already 5 months development. Add 1 month because no one is willing to
hold people to these dates. So that's 6 months. Then for 6 months of
development, you need at least 2 months of beta. So we're already in the
middle of July, everyone is on vacation, and we'll easily reach the 9
months -- instead of 6.
Do you think that 2 months for beta is realistic? Tom announced feature
freeze on July 1.
http://archives.postgresql.org/pgsql-hackers/2003-07/msg00040.php
So 7.4 took about 4.5 months to get from feature freeze to release. I
think feature freeze is the important date that developers of new
features need to concern themselves with.
I agree with Peter's other comment, that the longer the development
cycle, the longer the beta / bug shakeout period, perhaps a shorter dev
cycle would yield a shorter beta period, but perhaps it would also
result in a less solid release.
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
Marc G. Fournier writes:
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...OK, here start the problems. Development already started, so April 1st is
already 5 months development. Add 1 month because no one is willing to
hold people to these dates. So that's 6 months. Then for 6 months of
development, you need at least 2 months of beta. So we're already in the
middle of July, everyone is on vacation, and we'll easily reach the 9
months -- instead of 6.
'K, Sept 1st it is then ... sounds reasonable to me :)
"Matthew T. O'Connor" <matthew@zeut.net> writes:
So 7.4 took about 4.5 months to get from feature freeze to release.
I think feature freeze is the important date that developers of new
features need to concern themselves with.
Rather than the length of the release cycle, I think it's the length
of the beta cycle that we should focus on improving. IMHO, we should
try to make the beta process more efficient: sometimes I get the
impression that the beta process just drags on and on, without the
extra time resulting in a huge improvement in the reliability of the
.0 release (witness the fact that all the .0 releases I can remember
have had a *lot* of serious bugs in them -- we can't catch everything
of course, but I think there is definitely room for improvement).
That said, I'm not really sure how we can make better use of the beta
period. One obvious improvement would be making the beta announcements
more visible: the obscurity of the beta process on www.postgresql.org
for 7.4 was pretty ridiculous. Does anyone else have a suggestion on
what we can do to produce a more reliable .0 release in less time?
-Neil
Neil Conway wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
First, if you develop something today, the first time users would
realistically get a hand at it would be January 2005. Do you want
that? Don't you want people to use your code?Sure :-) But I don't mind a long release cycle if it is better for
users.
Given that users can run whatever they like, it's not clear that a long
release cycle is better for users.
(c) As PostgreSQL gets more mature, putting out stable,
production-worthy releases becomes even more important. In
theory, longer release cycles contribute to higher quality
releases: we have more time to implement new features properly,
polish rough edges and document things, test and find bugs, and
ensure that features we've implemented earlier in the release
cycle are properly thought out, and so forth.
On the other hand, the longer you wait to release a new feature, the
longer it will be before you get your REAL testing done. You don't want
to release something that hasn't at least been looked over and checked
out by the development community first, of course, but waiting beyond that
point to release a new version of PG doesn't help you that much, because
most people aren't going to run the latest CVS version -- they'll run
the latest released version, whatever that may be. So the time between
the testing phase for the feature you implement and the version release
is essentially "dead time" for testing of that feature, because most
developers have moved on to working on and/or testing something else.
That's why the release methodology used by the Linux kernel development
team is a reasonable one. Because the development releases are still
releases, people who wish to be more on the bleeding edge can do so
without having to grab the source from CVS and compile it themselves.
And package maintainers are more likely to package up the development
version if it's given to them in a nice, prepackaged format, even if
it's just a source tarball.
Note that whether or not we are using those 355 days effectively
is another story -- it may well be true that there are we could
make parts of the development process much more efficient.Furthermore, longer release cycles reduce, to some degree, the pain of
upgrades. Unless we make substantial improvements to the upgrade story
any time soon, I wouldn't be surprised if many DBAs are relieved at
only needing to upgrade once a year.
But DBAs only "need" to upgrade as often as they feel like. Any
reasonable distribution will give them an option of using either the
stable version or the development version anyway, if we're talking about
prepackaged versions.
The longer you develop, the more parallel efforts are underway, and
it becomes impossible to synchronize them to a release date.I think this is inherent to the way PostgreSQL is developed: Tom has
previously compared PostgreSQL release scheduling to herding cats :-)
As long as much of the work on the project is done by volunteers in
their spare time, ISTM that coordinating everyone toward a single
release date is going to be difficult, if not impossible. The length
of the release cycle doesn't really effect this, IMHO.
Linux, too, is done largely by volunteers in their spare time. Yet
Linux kernel releases are much more frequent than PostgreSQL releases.
One difference is that the Linux community makes a distinction between
development releases and stable releases. The amount of time between
stable releases is probably about the same as it is for PostgreSQL. The
difference is that the *only* releases PostgreSQL makes are stable
releases (or release candidates, when a stable release is close).
That's something we might want to re-think.
--
Kevin Brown kevin@sysexperts.com
