> In any case, I don't accept this analogy. The mechanics of a Linux
> distribution are very different from the mechanics of a project like
> PostgreSQL. The prominent OSS project that seems to me most like ours is
> the Apache HTTP project. But they don't do timed releases AFAIK, and
> theirs is arguably the most successful OSS project ever.
I can't find information about HTTPD release planning so I'll take your
word for it. On the other hand, I have to point out that Apache is
releasing HTTPD major versions an average of once every 3 years. I
don't think we want to go to 3 years, do we?
> I'm especially resistant to suggestions that we should in some way
> coordinate our releases with other projects' timings.
Agreed, that's impossible. I'd prefer just to time things so that we're
not trying to do committer-critical tasks during high summer vacation
season.
> I am not saying timed releases are necessarily bad. But many of the
> arguments that have been put forward to support them don't seem to me to
> withstand critical analysis.
There are several reasons to have a timed release schedule, which are
detailed in the paper I linked. The benefits of having timed releases
are for our contributors and for our users.
> I would argue that it would be an major setback for us if we made
> another release without having Hot Standby or whatever we are calling it
> now. I would much rather slip one month or three than ship without it.
Historically, any feature which hasn't been ready for the originally
planned release date needed far more than an extra month to be ready --
up to an additional year. HOT is the only exception I can think of to
this in our 13-year history.
I agree that HS is critical to adoption of PostgreSQL. However, the way
to make it succeed is to have deadlines and meet them. Not work on it
"until it's ready".
>> I personally suspect PostgreSQL would want a 1 year cycle for major
>> releases while a full dump/reload is required for upgrades. When this
>> changes, 6 or even 4 months might actually be a good fit.
>>
>
> For some DBA specialist is 1 year cycle too much fast. I thing, so 1
> year cycle is perfect for databases. Migration to new database
Pavel is right. Upgrade-in-place will become easier, but it will never
become painless. So DBAs will always want to put off upgrades to once
in 2-3 years. If we went to releases ever 6 months, that would mean
users skipping 5 versions.
Also, we backpatch fixes a lot more than Ubuntu does AFAIK. So we'd
still have to patch back 5 years, which would be 10 versions ... I
don't think so.
Once/year is the right length for us. It's 2x to 3x faster than any
other mission-critical DBMS.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
