Re: [PATCH] Framework shlib versioning

[Jeff Teunissen]

Nicola Pero wrote:

> > Some time ago, we had a discussion about frameworks and framework
> > mobility. One of the things that I brought up was that frameworks are
> > not versioned.
> >
> > Well, it turns out that frameworks _are_ versioned, but the version
> > used is that of the $(VERSION) make variable, otherwise only used for
> > building distributions.
> >
> > Attached is a patch that makes the shlib version and soname filenames
> > contain a framework's version name. If a version name contains one or
> > more periods, it will be split as normal to form the soname filename.
> >
> > Most of the patch is actually a target.make change that causes this
> > change to not be circumvented by the shared library build system for
> > the cases where the version filename and the soname filename are the
> > same (like the default case of "A").

[snip]

> Thanks.  Looks interesting.  I'd definitely agree that using VERSION is
> not a good idea :-) that's a 'global' variable, while we'd need a
> version for each framework.

[snip]

> <thinking>
> 
> I wonder why xxx_CURRENT_VERSION_NAME is used in frameworks, and not
> simply xxx_VERSION (easier to remember, and the same name could be used
> for libraries).

It's because just about any arbitrary filename-component string can be used
as a version name. All of these are existant framework versions on my
OPENSTEP system:

A
B
1998G
1999C
1.2
2.3.1

> Btw why do frameworks have 'A' as default version and not '1.0.0' ? 
> 'A', 'B', 'C', ... is very limited as a range of versions ... you can
> only have 26, and there is no difference between major/minor/subminor
> releases.

That's because version names (like soname versions) are not related to
release numbers. You only change the version name when your framework has
become binary-incompatible.

The default name is probably arbitrary, but follows sorting rules. Version A
is later than version 1, but earlier than version Albatros. This may cause
problems if we move to a number-based default version name.

By the way, there's a question in the makefile as to the effect of
xxx_DEPLOY_WITH_CURRENT_VERSION. It is there so that you can install a
version of a framework that is not to become the default. In our case, that
means that the Current link should not be changed while installing, and that
the version being installed should not have the .so symlink updated to point
to it. It should probably be a Master variable, not an Instance variable,
because of this.

> I'm now very tempted to do the following changes -
> 
>  introduce a PACKAGE_VERSION variable which should be used instead of
> the current VERSION variable for versions of packages (if
> PACKAGE_VERSION is empty, the value is set from VERSION, so it's
> backwards compatible)

That's good.

>  introduce a xxx_VERSION variable both in libraries and frameworks (if
> xxx_VERSION is empty, the version is set from xxx_CURRENT_VERSION_NAME
> (for frameworks only, for backwards compatibility) if that is not empty,
> else, it is taken from VERSION (backwards compatibility again), else
> it's set to 1.0.0 (please note that this would be done for frameworks
> too, instead of 'A'))
> 
>  replace any usage of CURRENT_VERSION_NAME with VERSION in frameworks

I don't like this, for the simple reason that it means a framework has two
different version strings that may not be the same. The version name has a
distinct link to the structure of the framework.

In addition, a framework version must not ever have an empty version name.
It's needed for finding that version's resources. Changing the default
version name to a number-based form is probably fine, but it will cause
framework rebuilds to leave duplicates behind.

[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.

By the way, NeXT used names instead of numbers for all of their dynamic
libraries, not just frameworks. For example, libsys_s.dylib on OPENSTEP is a
symbolic link to libsys_s.A.dylib, and libperl.dylib is a symlink to
libperl.5.dylib. The 5 was used for perl because it was perl 5, the fifth
binary-incompatible version of the lib, and because it matched with the
version on the other platforms Perl worked on. Obviously, libsys_s never
became binary-incompatible. :)

> Anyway, thanks Jeff for your help and contribution, much appreciated!
> :-)

NP

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