Re: Why new features only in magior releases ? - Mailing list pgsql-hackers

From Gaetano Mendola
Subject Re: Why new features only in magior releases ?
Date
Msg-id 40AA7F3F.1000104@bigfoot.com
Whole thread Raw
In response to Re: Why new features only in magior releases ?  (Neil Conway <neilc@samurai.com>)
Responses Re: Why new features only in magior releases ?  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
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












pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Relocatable installs
Next
From: Peter Eisentraut
Date:
Subject: Re: Call for 7.5 feature completion