Re: [PATCH] Framework shlib versioning

[Nicola Pero]

> My proposal allows for (specifically) a secondary "release version" to help
> distinguish the release name of a package from the version of the
> implemented interface; otherwise people will often do incorrect things like
> changing the interface version for no reason other than making a new
> release. With the separation people will still do that, but it should happen
> less often.

Oh yes - I get your proposal quite well, and I actually quite like it -
the only issue where our opinions differ is if resources should be keyed
under the release version or the interface version.

I'd like now to come to a conclusion and finish making the changes so this
can go live.  My solution would be as follows -

 library and frameworks will have a VERSION and an INTERFACE_VERSION.

 If INTERFACE_VERSION is not provided, it will be generated automatically
by VERSION by removing everything after (and including) the last dot, or
if there is no last dot, INTERFACE_VERSION will just be the same as
VERSION.

 INTERFACE_VERSION will be used in building the sonames of the libraries
exactly as it is now (I think it's called SONAME_VERSION or something).

 In the case of libraries, that's all of it.

 In the case of frameworks, you'll have 

  jeff.framework/Versions/$full_version/...

 because of the way symlinks are used in the sonames, while you can have
multiple full_versions installed at the same time, only one, for each
interface versions, will be active/used at any time.  If you install a new
framework with a different version but the same interface version as a
framework you already had, it will take over silently (at least, if you
use the flag xxx_INSTALL_AS_CURRENT_VERSION or whatever we agree to name
the flag).

 On Apple, where the soname symlinks are not used, the full_version can't
be in the path without preventing the interface_version from working as
expected, so Apple frameworks will be built according to Apple usage -

  jeff.framework/Versions/$interface_version/...

that sort of reduces functionality as you can't have multiple
full_versions with the same interface_version installed at the same time,
but only marginally as I agree almost no user will actually use that
functionality - most of them will have a single interace_version framework
installed at any time. :-)

Does this make sense ?

Your interface version idea/mechanism would then be totally integrated in
gnustep-make both for libraries and frameworks, which is good. :-)