Why new features only in magior releases ?

Gaetano Mendola wrote:

I well understand the reason to wait a 7.5 in order to delivery
BIG changes that are requiring a initdb, but I don't understand
why little enhancement can not be delivered in a 7.4.3 ( may be
with a short period with a 7.4.3beta ) like the "vacuum delayed".

I don't think this is a good idea.

It would risk destabilizing a known-to-be-stable release series. It is
very important that we keep 7.4.x a platform that people feel
comfortable deploying in a production environment.

It would also require additional development resources to back port the
changes, and do the (fairly extensive) testing required to verify that
they haven't caused any regressions (see the point about stability
above). We have a finite amount of development resources, and I think
the past consensus is that they are best spent developing for the next
major release.

I think that delivering some improvements in the 7.4.3 will permit
to delay a month the 7.5 without the pain to wait too long for some
enhancements.

Even without new features in 7.4, I don't really see the danger of a
slow-paced 7.5 release: production environments aren't eager to upgrade
their DBMS every six months, and the pain of an initdb applies no matter
how frequently we make major releases.

-Neil

Neil Conway wrote:

Gaetano Mendola wrote:

I well understand the reason to wait a 7.5 in order to delivery
BIG changes that are requiring a initdb, but I don't understand
why little enhancement can not be delivered in a 7.4.3 ( may be
with a short period with a 7.4.3beta ) like the "vacuum delayed".

I don't think this is a good idea.

It would risk destabilizing a known-to-be-stable release series. It is
very important that we keep 7.4.x a platform that people feel
comfortable deploying in a production environment.

Then we miss a degree in the versioning. I'm with you about:

1) Avoid init db if the BIG version not change
2) Avoid to introduce instability in a "know-to-be-stable" release

but wait "one year" for little improvement that for sure are not going to
jeopardize the two points aboce is too much IMHO ( see the vacuumdb delayed ).

It would also require additional development resources to back port the
changes, and do the (fairly extensive) testing required to verify that
they haven't caused any regressions (see the point about stability
above). We have a finite amount of development resources, and I think
the past consensus is that they are best spent developing for the next
major release.

Currently some changes are back ported to old branches ( BTW, why not to
switch to use "subversion"? ) so I don't think this actualy a big issue,
some times some improvments introduced in the BETA cicle are just postponed to
next version, so some times there is no back porting but "front" porting.

I think that delivering some improvements in the 7.4.3 will permit
to delay a month the 7.5 without the pain to wait too long for some
enhancements.

Even without new features in 7.4, I don't really see the danger of a
slow-paced 7.5 release: production environments aren't eager to upgrade
their DBMS every six months, and the pain of an initdb applies no matter
how frequently we make major releases.

I agree, for this reason I'm for introduce in old version ) that avoid
to perform an initdb) future enhancements.
We are running our DB in an RedHat HA cluster and upgrade from 7.X.Y -> 7.X.Z
for us is just an "eye blink", rpm -Uvh on the backup node, we relocate
the service, rpm -Uvh on the main node; all this with a total outage of
less then one minute.

Regards
Gaetano Mendola

Gaetano Mendola wrote:

Currently some changes are back ported to old branches ( BTW, why not to
switch to use "subversion"? ) so I don't think this actualy a big issue

The only changes that are presently backported are bug fixes that the
committing developer feels confident will not cause a regression (for
this reason, it is common practice to commit a simplified version of a
change to the stable release series, and a more complete rewrite to
-devel). It would require significantly more work to backport larger
changes -- both due to code drift in the development branch, and the
likelihood that larger changes that introduce new features will require
a lot more testing than small changes that fix critical, localized bugs.

(Of course, one option for users who want new features in a stable
release series is to hire a company to backport them for you. It is
already common practice for some companies to support PostgreSQL
releases for longer than the development group is prepared to do.)

As for using SVN, that's been suggested before (there was a long thread
on it recently). I wouldn't object, although (a) I don't see the rush,
CVS works fine for us AFAIK (b) arch might be worth considering as an
alternative.

-Neil