On Thu, 2008-09-25 at 21:12 +0200, Henrik Nordstrom wrote: > On tor, 2008-09-25 at 23:36 +1200, Amos Jeffries wrote: > > Hmm, so rolling DEVEL + PRE + RC into one version called a.b.0.N > > Well, I'm a little doubtful but can't argue against that yet. > > No, not quite. > > There is no point of DEVEL releases in the current form of the > development cycle. So we skip those. The nightly snapshots is good > enough for that purpose. > > PRE relesaes is the main needed release while trying to get the branch > in shape. These is the 3.1.0.N releases where N >= 1. > > RC using the actual release version. The forst RC for 3.1 would be > 3.1.1. And if fine (which it should be) this is the same tarball which > then gets promoted to "stable for production use".
I thought we would use RC label for selected/last 4-digit releases. > If there is a problem with the RC then there is two choices. Either skip > the release number and number the "stable" release 3.1.2, or reroll > 3.1.1. Which one depends on if the RC has been distributed. Quite often > RC level errors is detected immediately even before announcing it to > squid-dev.. If we use RC label for selected/last 4-digit releases, then we will not have the above problems. If a 4-digit release proves stable, we post 3.1.1 (an exact copy of the last successful 4-digit release, except for the version number) and mark the branch as stable. Is there a reason we cannot have "stable candidates" using 4-digit versions? Cheers, Alex.
