bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository

[Diego Elio Pettenò]

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
address@hidden — http://blog.flameeyes.eu/