pre-release update of LTDL_VERSION_INFO (was: [SCM] GNU Libtool branch, master, updated. v2.4-1-gf0ba93d)

[Ralf Wildenhues]

Hello Gary,

* Gary V. Vaughan wrote on Fri, Sep 24, 2010 at 10:12:10AM CEST:
> On 23 Sep 2010, at 00:30, Ralf Wildenhues wrote:
> > * Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 06:27:27PM CEST:
> >>    * libltdl/Makefile.inc (LTDL_VERSION_INFO): We've added the
> >>    static libprefix interface, so new version-info is C+1:0:R+1.
> > 
> > libprefix is a *static* local undocumented variable, not public API.
> > There was no reason to bump the API version for this.  :-(
> 
> Ugh.  Sorry.  Luckily there are still quite a lot of numbers left
> before we run out.

That's not the point.  The point is that on systems which compute the
major version as CURRENT rather than CURRENT - AGE, this bump means
that all dependent libraries need to be rebuilt.  For the respective
distribution packagers, I expect this to be several hours of extra
work.  This affects for example FreeBSD and systems derived from it.

Incompatible changes (bumping CURRENT) are *very* costly for
distributions, and more importantly, they typically hurt the
acceptance rate of the software.

> I propose that to avoid this problem with future releases, that
> whoever commits a change that *does* affect LTDL_VERSION_INFO notes
> it in NEWS so that I don't make another mistake when I'm searching
> back up ChangeLog from the previous release commit to find things
> that affect the API versioning.
> 
> If you agree, I'll add a note to HACKING.

How about this alternative: the person doing the release posts the
proposed patch to bump the version info for public review, it gets
properly reviewed, then it gets committed?

If you agree, I'm fine if that is documented in HACKING.

The rationale for this approach is that it is easy to forget this
requirement during development, both as developer and as reviewer,
and it is less work to overlook all past changes at one time during
the release.

Of course API changes, compatible or not, should still be announced in
NEWS, but they weren't this time, because there were none.  It's part of
release management to check and ensure that this is indeed correct.

Thanks,
Ralf