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
