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

[Christopher Armstrong]

Hi

I don't know if this helps, but these are my ideas for what I think 
should be happening; I think we're still trying to work out the details 
and trying to keep an open mind before coming to any firm decisions. 
Personally, I believe that anything that is done will leverage present 
features and options that permit versioning.


David Ayers wrote:
> 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?

I think most of this discussion is related to the versioning of 
libraries and frameworks. Applications may exist on a system that depend 
on different versions of a framework or library, where these library 
versions are ABI incompatible. This is the main area I see as needing a 
solution for versioning.

It would be expected that if a user tried to install a different version 
of an application or tool (essentially highest level application entity) 
that the previous version is replaced, at least in the same GNUstep 
install. Multiple GNUstep installs should be relatively independant, but 
probably not tolerated on user systems, but only developers where they 
are more in control.

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

Definitely not. The Objective-C runtime can't load two different 
versions of the same library. This can become fuzzy, however. Gorm's 
version of base would be loaded as it is the application and its 
libaries need to be loaded before DBModeler. If the parts of 
gnustep-base that DBModeler uses are ABI compatible with the old version 
(by coincidence) it may still work. However, this would rely on both 
libraries having the same name on Windows (i.e "gnustep-base.dll"). If 
the library names were different, DBModelers version of gnustep-base.dll 
would load and mess up the runtime (behaviour is nasty and undefined AFAIK).

> - Could Ink.app and TextEdit.app copy & paste?
> - How are will services running with different versions communicate with
> applications running with different versions?

Mostly communication between applications is IPC, so sockets or the like 
would need to be used and different library versions shouldn't pose a 
problem if the communication protocol being used is the same (like web 
browsers talking to web servers on different systems and different 
platforms). If the communication protocols across sockets are the same, 
I wouldn't expect this to be a problem. If there was a difference, who 
knows?

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

I agree with this. Keyed archiving would alleviate the situation, but 
things like this work on a case by case basis. Likely to be software 
developers who decide whether a new version will need to be distributed, 
compiled against the new library versions.

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

Part of the solution is the versioning mechanisms we provide. The other 
half is responsible software developers using these mechanisms properly 
with their own applications and libraries so that things remain backward 
compatible.

My personal choice is frameworks, as they allow the developer to decide 
when a new version of a library is not compatible with the old. I think 
we should consider supporting these as best as we can. On windows at 
least, we can then use library names such as "gnustep-base.dll" instead 
of "gnustep-base-011.dll" and avoid having multiple DLLs attempting to 
be loaded into a programme due to bundles linking against different 
versions. I still consider a loader application with linking tools and 
applications as DLLs as a reasonable solution for Windows, as we can 
then exploit the full power of frameworks and the relocatability of 
applications. I believe the AppPath method is also very reasonable 
although I do worry about Windows' ability to manage it correctly. Plus 
we still need a way to set all our environment variables reliably 
(without resorting to setting them permanently, although WiX definitely 
support this well).

Cheers
Chris