automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases


From: Stefano Lattarini
Subject: Re: bug#13578: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
Date: Tue, 12 Feb 2013 17:44:06 +0100

On 02/12/2013 04:15 PM, Diego Elio Pettenò wrote:
> 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.
>
Ah, right.  I had forgot about that (selective memory? A dangerous
thing).

>> 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..
>
That is not something automake can do anything about.  Releasing
beta versions whose version numbers suggests they are actually
stable versions is a solution worse than the problem.  But you might
correctly point out that, due to lack of proper testing, this is
already what we are doing right now (albeit not by choice); so the
issue becomes at this point a documentation issue (that is, we should
find a way to inform the users that early stable versions of new major
releases might turn out to be lamentably unstable in practice, if
nobody has given the betas proper testing).  See again below.

>> 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.
>
This sounds sensible, but I think it should be done in addition to the
usual release of "classic" beta versions (with the hope that someone
will get to testing them eventually).  And if we agree on this approach,
the only required change would be a new section about this versioning
and stability issues in the Automake manual (and/or in the Autotools
Mythbuster guide).  As usual, patches are welcome (this is not really
my itch).

>> 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.
>
That happened with Python as well, and I guess with many other softwares
who did a major version bump with non-trivial backward incompatibilities.

> 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.
> 
Ah, ok, so in the end you already agree that this is a "documentation"
issue rather than a versioning one.  Please correct me if I'm wrong!

Thanks,
  Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]