Re: [HACKERS] CVS Branch Tagging... - Mailing list pgsql-hackers
From | The Hermit Hacker |
---|---|
Subject | Re: [HACKERS] CVS Branch Tagging... |
Date | |
Msg-id | Pine.BSF.4.05.9810220832090.3048-100000@thelab.hub.org Whole thread Raw |
In response to | Re: [HACKERS] CVS Branch Tagging... ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Responses |
Re: [HACKERS] CVS Branch Tagging...
|
List | pgsql-hackers |
On Thu, 22 Oct 1998, Thomas G. Lockhart wrote: > > While it will be possible, I would like people to concentrate on the > > existing 6.4 issues we have, and discourage parallel development on > > separate final and features source trees. > > As Bruce describes, a "quiet time" just before and up to a month after a > major release is a _really_ good idea. For a couple of reasons: > > 1) it lets us put out bugfix releases with a minimum of trouble > > 2) it lets people planning larger changes for the next release to work > on a stable, quiet tree, with some assurance that they will likely be > able to remerge their work when things unfreeze. I don't agree...the problem is that our times between releases tends to be...erratic. It was supposed to be 3+1mos, and is turning into, what, 5+1? Not all changes to the source tree require a dump/reload to take effect...we have 4 patches in the ftp site right now, to v6.3.2, with the first dated Apr21st, and the last dated Jul30th. With a STABLE vs CURRENT branch, those patches could have been applied to the STABLE branch, and a quick v6.3.x release could have been regress tested and released. That in itself would have saved some of the problems where ppl had downloaded the 'newest release' but had problems because they didn't grab the patches to go along with it. The problem right now is we look at it as being one stream...right now, the only thing that should be left for v6.4 is bug fixes, and there should be no reason to hold up continued development while we wait for each possible bug report to flow in. With two branches, there should be no reason why a patch that Vadim comes up with to fix a "rarely hit, but often disastrous" bug in indexes can't be applied and tested in both tree. Then a quick v6.4.1 can be released that those not wishing to run "latest and greatest" can run without having to lose out on that major fix... The idea is that with very little work on anyone's part, we can easily provide a more stable foundation for those starting out and wishing to use it in a production environment. Right now, we have a v6.3.2 from April 19th, with four patches that can be applied...but how many ppl would actually apply those patches in a production environment? Most ppl would download and upgrade to v6.3.3 which had those patches applied... I don't know...its something we just did with INN, cause we still had some bugs to work out on 2.2, but some of the developers who don't work on the areas involved are getting restless to get some work done...gives them a chance to move forward without affecting the RELEASE scheduale... Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
pgsql-hackers by date: