Re: [PATCH] Framework shlib versioning

[Jeff Teunissen]

Nicola Pero wrote:

[snip]

> Thanks for the explanation.  Interesting!  It probably needs more work
> then - your point is very good, if we could implement so that it works
> as you say and still it is an instance variable, that would be the best
> thing. :-)

As an instance variable, it should be shorter, so you can give make the
variable on the command line.

[snip]

> I think that a framework should have a single version string, so that
> you know that libMyFramework.so.1.4.5 is using the resources in
> Versions/1.4.5/Resources (or, if you prefer letters or a general version
> string, libMyFramework.so.C is using Versions/C/Resources).
> 
> Otherwise it'd be a bit difficult (impossible ?) to match resources with
> the shared libraries.
> 
> 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).

How about:

_VERSION for the version of the package (in the info plist, if any),
defaulting to 1.0.0 or even 0.0.1

_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).

_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". :)

[snip]

> > > Any comments before I do these changes ?  Particularly on why the
> > > default framework version should or should not be 'A' versus
> > > '1.0.0'. To me '1.0.0' looks a much better choice, but I'm open to
> > > do differently if given a good reason :-)
> >
> > It's not particularly important. I believe that the decision at NeXT
> > to do this seems pretty arbitrary. Maybe it holds some meaning in that
> > it drives home the notion that you shouldn't change the version name
> > too lightly, and perhaps that it's not related to the version
> > name/number of your package.

[snip]

> Ok - I think switching to 1.0.0 is OK then.

As do I.

> Thanks for your time, I really appreciate your help.  It's not easy to
> get frameworks right without some helpful suggestions :-)
> 
> Thanks for your comments and for taking time to discuss this issue with
> me.

No problem.

-- 
| 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/