On 2/26/06, David M Johnson <[EMAIL PROTECTED]> wrote: > Milestones > May - Roller X.Y.1 good release, voted up to GA status > June - Roller X.Y.2 not so good, just considered a alpha > July - Roller X.Y.3 not so good, just considered a beta > August - Roller X.Y.4 good release, voted up to GA status > > A user upgrading from X.Y.1 to X.Y.4 needs to incorporate database > schema changes that were made in releases that never got the > official seal of approval. Isn't that a problem?
Not that I can see. Each of these distributions would have contained the scripts current to that build. The user would just use whatever script came in the distribution. By the time we got to * September - Roller X.Y.5 usually, we would already know if X.Y.4 made the grade or not. * If not, we could rename X.W-to-X.Y.4 to X.W-to-X.Y.5. * If it did go GA, and the database changes continued, we could just start a new X.Y.4-to-X.Y.5 file. One of the reasons that HTTPD started to use this scheme is because it lessens the need to freeze the codebase. Each milestone is a snapshot, we roll the milestone, and we get back to work on the next milestone. -Ted.