On 12/02/2013 09:26, Stefano Lattarini wrote: >> Given that 1.12.0 was "not really final release", >> > Why not?
AM_PROG_MKDIR_P. > This is true, but is only due to the fact that I released them with > too much haste, without giving time for proper testing. IOW, this > debacle has been a fault of mine, not of the naming scheme. True, but it shows a pattern: most people (even developers who get involved in the process, such as Paolo) do not even look at the beta versions.. > I don't see any need for this; everyone knows that a new major release > is more likely to contain bugs and rough edges. (OTOH, this is not > excuse to be sloppy and hastily in the release process as I've been > for 1.13; but avoiding repeating the mistake in the future will only > require more care and attention from the maintainer, and not a change > of policy). True, but a new beta also is also more likely to contain bugs and rough edges... so it's basically the same thing, thus why I'm saying that it should just be the same. Put out the new major at "not stable yet", try it out all around, then make a release to call it stable. > Any link about this? The info I found on Google doesn't seem very > helpful nor relevant. I'm afraid I don't have anything that Google wouldn't have. But at least for 2.2, it was declared stable much later than ".0" if I'm not mistaken. Basically, it would be like making policy that the new major branch is not stable until we say it is.. which is really what we need. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
