RE: Versioning [was: Re: Symlinks from Tools to Applications]

[Nicola Pero]

Well, having library resource versioning is a good enhancement in general. :-)

For example, I don't see any problems with having Renaissance-0.8.0
and Renaissance-0.9.0 being used by different applications at the same time.
There is no conflict in doing so, and the two different library versions
might need to use different resources. ;-)

Of course, as you point out, gnustep-base/gnustep-gui are a special case
because they consitute the core framework; they allow applications to
talk to each other and they have those communication daemons running ...
if you have two completely conflicting gnustep-base libs in use at the
same time, it would just be a mess. ;-)

But if we have a general library resource versioning system (which in most
cases of library is very useful) it makes sense to use it in gnustep-base
and gnustep-gui as well ... even if running two concurrent versions of
gnustep-base/gnustep-gui might be necessarily be a clever thing to do. ;-)

In some cases, maybe in most cases, it would work pretty well though.
Eg, if you have gnustep-gui v1 and gnustep-gui v2 that can communicate
well, but where gnustep-gui v2 has a very slightly different API (maybe 
some methods were added or removed), and needs some different resources 
(maybe the DataLink panel was rewritten and now there are different buttons 
in it, so it needs a different .gorm file).  In that situation, you can have 
different apps use different versions of gnustep-gui and having library 
versioning allows you to run the two gnustep-gui libraries at the same time. :-)

Anyway I personally consider the library resource versioning in 
gnustep-base/gnustep-gui
mostly as a worked-out exercise of how you use library resource versioning in
your own library. ;-)

Finally, you could already install and link multiple conflicting versions
of gnustep-base - the library resource versioning support doesn't change this. 
:-/

About long-term binary compatibility, I believe that putting library resources
in versioned directories structured in the same way as the traditional 
frameworks
make the two more similar to each other and will make it easier to share
code and/or to switch from libraries to frameworks (and vice versa), which is
a good thing. :-)

Sorry for the long, dense email -- hope it clarifies the idea behind the stuff 
:-)

Thanks

PS: The point you're making is very good with respect to the Windows discussion
though, where it's really hard to decide what to do with respect to versioning. 
:-/


-----Original Message-----
From: David Ayers <ayers@fsfe.org>
Sent: Sat, March 10, 2007 12:55 pm
To: nicola.pero@meta-innovation.com
Cc: discuss-gnustep@gnu.org
Subject: Versioning [was: Re: Symlinks from Tools to Applications]

Hello,

I am still missing a clear concept of how versioning (on any platform)
should really work in practice.  I am concerned because we may be
burdening the trunk with experimental approaches that affect the new ABI
defined by -make v2 which may lead to further ABI instability in the future.

Let me try to formulate my concern more precisely.  I'm trying to
imagine a system with multiple versions of -base and -gui.
- Would this system have two versions of gpbs/gdnc running simultaneously?
- If I started Gorm with linked against the older version of -base,
could it communicate with DBModeler linked against the newer version via
Drag & Drop?
- Could Ink.app and TextEdit.app copy & paste?
- How are will services running with different versions communicate with
applications running with different versions?

>From my understanding any system with mixed versions will mostly work by
chance rather than by design.  Now keyed-archiving (if thoroughly
implemented in all running versions) may alleviate this concern to some
degree.

But I still have the feeling that effort attempting to support versioned
libraries in an environment based on integration and delegation in such
a degree as GNUstep does, may be disproportionate compared to the added
value.  Don't take me wrong, if there is a concept on how these
scenarios can work, and they don't result ABI instability for the
standard linear migration paths, I'm all for it.  I guess I'm just
missing the clear picture on where these changes are headed.

Cheers,
David