On Tue, Feb 12, 2013 at 9:38 AM, Stefano Lattarini <stefano.lattar...@gmail.com> wrote: > On 02/12/2013 09:25 AM, Miles Bader wrote: >> 2013/2/12 Stefano Lattarini <stefano.lattar...@gmail.com>: >>>>> But what if we want to have multiple betas for, say, Automake 1.14? >>>>> Today, >>>>> we can just have 1.13b, 1.13d, 1.13f, ...; how can we do so with the >>>>> scheme >>>>> you are proposing? >>>> >>>> There's always 1.14.0.1, ... >>>> >>> Yuck; the new versioning scheme is done exactly to avoid that kind >>> of overly long version numbers >> >> Well, I agree in general that too many components is yucky, but keep >> in mind that these _aren't releases_, so assigning them "awkward" >> version numbers doesn't really seem all that annoying. These really >> aren't part of the historical record. The existing naming scheme for >> betas does the same thing (uses "weird" version numbers), but is >> problematic because it's not mechanically consistent with "ordinary" >> version numbers (and so screws up cases such as packaging software). >> > Mostly fair points; but the biggest issue with this proposal (not > sure why I didn't think of it before, sorry) is that it is not at > all clear that a version like "1.13.0.1" is supposed to be a beta > release. People will easily mistake it for a stable release. OK, > we can add warnings and info and whatnot in the manual and homepage > of automake about our unusual versioning scheme, but how many people > will read them? And in the end, even those who do will likely be > just annoyed by the fact that we are trying to be clever and invent > a new versioining scheme incompatible with every other existing one. > > No, if we want to change the versioning scheme for beta and rc > versions, we want the new scheme to be already used and well known.
in our project, we append _beta and _rc (or _rc1, _rc2 etc...) for beta and release candidate. It's sufficiently explicit. For example, 1.14.0_beta Vincent Torri