automake-patches
[Top][All Lists]
Advanced

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

Re: Patch: FYI: PR 304


From: Alexandre Duret-Lutz
Subject: Re: Patch: FYI: PR 304
Date: 24 Mar 2002 22:08:37 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>> "Tom" == Tom Tromey <address@hidden> writes:

 >>>>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:
 adl> - Richard's fix for &check_typo, allowing AC_SUBST's variables
 adl> with reserved suffixes is quite important, but it's also an API
 adl> breakage: if this went in 1.6.1, it would mean that a
 adl> Makefile.am which works with 1.6.1 might not work with 1.6
 adl> (although these two versions would be advertised as sharing the
 adl> same API).

 Tom> That's a difficult point, isn't it?  :-(

Yep, I feared this kind of discussion.

 Tom> When is an API breakage different from a simple bug?

I'm tempted to answer "always", however I guess it'll be easier
to agree on "when it break backward compatibility".  Besides,
that's how it is documented presently:

|    Note that `1.6' in `automake-1.6' is Automake's API version, not
| Automake's version.  If a bug fix release is made, for instance
| Automake 1.6.1, the API version will remain 1.6.  This means that a
| package which work with Automake 1.6 should also work with 1.6.1; after
| all, this is what people expect from bug fix releases.

Given the aforementioned check_typo change only breaks _forward_
compatibility, we could include it in 1.6.1 and I should stop
arguing and go update the doc with "however do not expect
forward compatibility: switching from 1.6.1 to 1.6 might not
work".

[...]

 adl> What about naming it 1.7?

 Tom> I'd rather not, but perhaps it is simplest to do that.

No problem.  While writing this mail I convinced myself I was
too extremist with these API issues.
-- 
Alexandre Duret-Lutz




reply via email to

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