Thread: Why new features only in magior releases ?

Hi all,
may be this was already discussed, I'm quite new to postgres
( only 3 years ), I try however.

I seen the debate around the time freeze for 7.5, who say to
wait in order to have more "chance" to have PITR, Win32, 2PC...
and who say that wait a month more will not change nothing.

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 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.



Regards
Gaetano Mendola

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