Re: [HACKERS] Why new features only in magior releases ?

2004-05-18 Thread Neil Conway
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
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org


Re: [HACKERS] Why new features only in magior releases ?

2004-05-18 Thread Gaetano Mendola
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





---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster