Re: platform compatibility policy

[Colm Smyth <Colm Smyth ireland sun com>]

>From: Maciej Stachowiak <mjs eazel com>
>
>Havoc Pennington <hp redhat com> writes:
>
>> A useful definition:
>>  Major version: 1.0, 2.0
>>  Minor version: 1.0, 1.2, 1.4
>>  Micro version: 1.2.5, 1.2.6

This is the scheme Sun uses. Note that the goal of this scheme is
to capture compatibility; it is not intended to limit the scope of
compatible extensions or enhancements to an API.

>> 
>> So we are defining our versioning scheme implicitly to match changes
>> in the devel platform. Major versions break bin/source compat.
>
>I thought about it some more and I definitely don't like codifying
>this release naming scheme. Version numbers are primarily marketing
>entities, let's not start assuming they encode piles of useful info,
>or we will look weird when we have to do what Sun did when they
>switched from Solaris 2.6 to Solaris 7. Let's just declare which
>releases are what level of platform release.

Hmm, lots changed between Solaris 2.6 and 7. The only reason
Sun will update the major version of a library is because there
is a binary incompatible change. Minor and micro changes are just ways
to signal bug-fixes and 100% binary interface compatible enhancments.

One such incompatible change in the update to Solaris 7
was the adoption of Motif 2.1, in addition to Motif 1.2.5.
Motif 2.1 had some very small API changes (I can only think
of exactly one actually) but more importantly it changed several
widget structures and altered the behaviour of XmString making
programs that assumed that an XmString was something like a char*
crash (a lot). Although those programs were broken (they did not
use XmString as it was intended to be used), we decided not
to break those applications and so we introduced a new shared library
major version; we continued to provide libXm.so.1 but also delivered
libXm.so.2. Applications that wanted to build against Motif 2.1
would link against libXm.so.2.

There was some discussion earlier about which interface enhancements
should be allowed in micro and minor version changes. I think that
so long as the enhancement in no way breaks compatibility, it does
not matter what changes arise. It's actually better not to introduce
a new library with a new major revision as applications then have to
decide which library version they are going to use; it gets complicated
if other system libraries depend on the original version of that library
- you definitely don't want a process to load multiple versions of the
same library!

I know that there was a suggestion that Havoc write up some standards
for the GNOME project, but this is actually something I know a fair
bit about. How about we co-write it, and re-use as much as we can of
existing 'best practices' where possible and appropriate
Liam Quin <liam holoweb net> suggested that it might be useful
to put an overview on binary-compatibility up on the GNOME site.
The docs I mailed could be cleaned up for this purpose and modified to suit
GNOME.

What do you guys think?

Colm.


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers