Peter Eisentraut <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
