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.

Reply via email to