Re: [PATCH] Framework shlib versioning

[Jeff Teunissen]

Nicola Pero wrote:

[snip]

> > > For this reason, I'd like to unify VERSION and CURRENT_VERSION_NAME
> > > which are currently separated.
> >
> > Hmm, perhaps they should be kept separate. The code version and the
> > interface version are different things, even if GNUstep revs the
> > version with every release (usually considered to be a bad idea).
> 
> Hmmm, yes, but this is a different difference :-)
> 
> Libraries already have a xxx_SOVERSION variable, which is different from
> xxx_VERSION, and it's automatically generated from the version but you
> can change it (normally if version is 1.4.5, soversion is 1, so that the
> dynamic linker will consider all versions 1.x.y as binary compatible;
> you can change this scheme to whatever you want, a common one for
> example is to use version 1.4.5 and soversion 1.4, so that only versions
> 1.4.x are considered binary compatible, but 1.5.2 is not compatible with
> 1.4.3).
> 
> So I quite like your suggestions, where xxx_INTERFACE_VERSION is just a
> new name for xxx_SOVERSION (and now available to frameworks too, which
> would be good),

[snip]

> > _INTERFACE_VERSION (libraries and frameworks), for the version of the
> > interface that the shared object and its associated resources refer
> > to.
> >
> > For libraries -- is the string used to form the .so version/soname,
> > and nothing else.
> > For frameworks -- used for .so version/soname and the name of the
> > Versions/(foo) directory. If not present, its value is taken from
> > _VERSION. As a convenience, a symlink with the value of _VERSION could
> > be installed pointing to the interface version's directory (if
> > _VERSION and _INTERFACE_VERSION are different).
> 
> but shouldn't the framework's Versions/ directory use the full version ?

No. I'll cover this below.

> You could have framework version 1.6.5 and version 1.6.6 which have the
> same API, are binary compatible, and they only differ because an image
> which was broken (wrong format or truncated or bad depth or in the wrong
> directory) in 1.6.5 has been fixed (or renamed?) in 1.6.6.

The shared libraries are binary-compatible, but the shlib is not the  whole
of the framework, and maybe not even the most important part of it (a
framework needn't always have classes -- it may be only resources and/or
headers). Framework resources (or for that matter, any bundle's) are not
internal to its code, but part of the interface -- a program that has a
bundle loaded (whether it was loaded manually or was bound to the program at
link time) can load resources from it using NSBundle. If the resources are
not compatible, then the interface is not compatible and needs a new
version. That is why framework resources are versioned identically to the
framework's shared object file.

> The frameworks are in all senses compatible, and 1.6.6 is just a bug fix
> of 1.6.5 where some resources have been
> fixed/renamed/moved/added/changed (with concurrent updates in the code
> internals).  Because of the difference in the resources (which might be
> internal to the frameworks), 1.6.5 might not be able to run using
> 1.6.6's resources.  So if you want to have both of them in your machine
> (maybe you've got 1.6.5 installed and are working on 1.6.6 so you want
> to install and test 1.6.6 but want to be able to easily get back to
> 1.6.5 by restoring a symlink), they need to have different resource
> directories.

If applications built with MyFramework v1.6.5 cannot use v1.6.6's resources
as if it were v1.6.5, then it is not binary-compatible. That's one reason
why the release version and the interface version should be split in the
first place. :)

If v1.6.6 is a compatible upgrade, the interface version does not need to
change, and the resources are (and should be) updated/added to in situ.

If you add symbols to a shlib but do not remove old ones, the shlib is said
to be binary-compatible. If you remove a symbol that can reasonably be
expected to have been used, you need a new soname version.

The same is true for resources; if you only add resources or update existing
ones (say you got some new icons), then there is no reason to change the
interface version, and v1.6.6 is a pure upgrade. You _may_ of course change
the interface version and require apps to be recompiled to use the new one,
but it's a needless waste of space for a mere upgrade.

Of course, this _is_ a new release, so the release version should still be
updated. With the convenience ReleaseVer->InterfaceVer symlink in place, you
can see this -- but as I said earlier, this would clearly be optional.

[snip]

> > _DEPLOYABLE (frameworks and potentially libraries), to supply a
> > decision to update symbolic links and, for libraries, headers. After
> > all, it is reasonable to install an older version to satisfy a
> > binary's dependencies or for other purposes. With the current setup if
> > you install an older version, it will overwrite the symbolic link and
> > the headers...oops, now you have to reinstall the newer version to get
> > your system back to normal. Obviously, this should default to "yes".
> > :)
> 
> I like the idea of _DEPLOY_WITH_CURRENT_VERSION renamed and used
> consistently by both libraries and frameworks.  Very nice.  We just need
> to find a good name :-)
> 
> I'm not totally convinced by _DEPLOYABLE - but I agree it's short and
> being short is nice, which makes it better than
> _DEPLOY_WITH_CURRENT_VERSION (even if this is a bit more expressive). 
> If we don't find anything better, I suppose we can use _DEPLOYABLE.

Other suggestions:

_MAKE_DEFAULT
_SET_AS_DEFAULT
_IS_DEFAULT

Also, could replace DEFAULT with STANDARD.

The reason I suggested _DEPLOYABLE (maybe with prefix _IS) is that the
variable means the interface version being installed can be used in
production, i.e. is stable, or not experimental. "can be deployed"

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/