On 2012/11/13 08:01, Woodhouse, David wrote: > On Fri, 2012-11-09 at 12:19 +0100, Marc Espie wrote: > > > > autocrap is part of the problem, not the solution. Their documentation > > concerning version numbering, and all the fuzz they add around it don't > > help at all. The "old" style (major.minor) is fairly simple to understand > > and to use, actually, as long as you don't try to play fucked up games with > > it. > > I've committed a patch to make it use -version-info on OpenBSD, and > -version-number with GNU libtool. They seem to do the same thing, taking > the sane ABI-version numbers that I give them, and putting them directly > in the filename of the resulting library. > > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/ada3dea0 > > I note you don't seem to have an soname — so if I add functions to > libopenconnect and bump the minor release number, I think your GNOME and > KDE authentication dialogs for the VPN are going to break. If you update > OpenConnect and not rebuild those, of course. I appreciate you say you > don't. But OpenConnect might occasionally have required security or > compatibility upgrades, so users might want to.
If people are installing software from packages, realistically they're going to have to follow packages for updates too - the package build infrastructure takes control of version numbers and enforces our own version numbers, so somebody building an updated OpenConnect themselves would need to update anything depending on it themselves (your major version number is beyond the one in packages, we start from 0.0 when something is first added to ports, largely as a check to ensure that the build infrastructure does handle overriding version numbers). Also besides changes in the packaged software itself triggering a version bump, sometimes we need to force libraries to get updated due to changes in the OS (very rare but occasionally necessary). The package tools keep track of library dependencies (rather than just package dependencies) and know that they need to update all depending ports if a lbrary is updated (and keep old libraries around in cases where not everything can be updated together). Unfortunately for every project like OpenConnect where developers are clear about how versioning works, there are probably 2 or 3 who don't, we do go as far as diffing source trees when updating to make sure we bump when needed and find that either bumps gets missed very often, or people just don't understand the rules at all (probably the most common error being projects which use their release version number for the library version irrespective of symbol changes). Within the patch branch for a stable release, we will backport important changes (manpower dependent..) if they don't break ABI, this does restrict what we can pull back a bit, however as our release cycles are fairly short (fixed six-monthly) this generally isn't a big problem in practice. (As far as the GNOME/KDE authentication goes, I believe this is via NetworkManager which we don't package at all, so I don't think this is going to affect us at present; I'm not sure of the current status of NM, but historically the HAL dependency made it too difficult). > Does that mean I should actually make it just '-version-info @APIMAJOR@' > and drop the ':@APIMINOR@' part for OpenBSD? I think it would make sense to keep both..
