Re: platform compatibility policy

[Colm Smyth <Colm Smyth ireland sun com>]

Hi Maciej,

>From: Maciej Stachowiak <mjs eazel com>
>Colm,
>
>Actually, I really appreciate your comments. I know Sun has a strong
>track record on compatibility issues.

Thanks. I think we need to put more effort into some technology
to help GNOME maintainers support compatibility; it must
be simple and straightforward both for the maintainers and the
users of GNOME's libraries to stay compatible. We can improve
tools like the AppCert tool suite to make it easier for developers
to spend more time creating features and less time solving version
dependency issues.

>There is a worry here that libraries that are not part of the devel
>platform (either because they are GPL or intentionally marked
>"internal use only" or whatever) would mistakenly be used
>unintentionally if they install headers. Maybe we should have these
>libraries insteall headers ina distinguished location
>($(includedir)/gnome-internal maybe?) to avoid people using these
>private but shared interfaces accidentally.

I think that's basically a good idea, but I wonder if it is
really necessary. Ideally only an internal part of a module
should use internal interfaces belonging to that module.
For example, GConf backends use internal interfaces of GConf,
but they are built within the GConf module tree so they can refer
to local include files (e.g. #include "gconf-internal.h"), not those
in the <gnome>/include directory (e.g. #include <gtk/gtk.h>).

Can you think of examples where an module needs to
use internal interfaces of another unrelated module?

>> If there is any interest in such a tool for GNOME, I can contact
>> the team at Sun responsible for AppCert to see if they
>> could contribute the AppCert tool-set to open-source
>> for use in the GNOME project.
>> 
>
>That would be a great contribution.

I'll contact the team and start the ball rolling.


On a slightly related topic, I find it can be time consuming to
create a complete up-to-date working GNOME build, especially
when some stable releases of GNOME modules can be identified
by CVS tags, while other parts must be downloaded as tar files.
I have some ideas that might help with this.

What do you think about the idea of having a STABLE file in the
root directory of each module that identifies the most recent
stable release version along with either the appropriate CVS tag
or the main distribution ftp URL?  This would be ideally
accompanied by a DEPENDS file that lists the most recent
known compatible version numbers of any dependent modules.

This is quite easy for each module maintainer to do and
it provides more information than can be obtained from the
configure script (usually a configure script checks *earliest*
known working versions of dependent libraries, but the
DEPENDS file would list the *latest* known working versions
of dependent libs).

Thanks,

Colm.


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