Re: Why new features only in magior releases ?
От | Gaetano Mendola |
---|---|
Тема | Re: Why new features only in magior releases ? |
Дата | |
Msg-id | 40AA7F3F.1000104@bigfoot.com обсуждение исходный текст |
Ответ на | Re: Why new features only in magior releases ? (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: Why new features only in magior releases ?
|
Список | 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 по дате отправления: