A GNOME Bindings release set?

[Murray Cumming Comneon com]

There has been various talk of getting some bindings into the GNOME Platform
recently. I don't think that's a good idea [1]. I think what people actually
want is some vague seal of official approval and some confidence that their
chosen bindings will continue to be maintained and in-sync with the C GNOME
Platform.

I suggest that we create a GNOME Bindings release set, with a schedule that
is in sync with the GNOME schedule. The GNOME release team and GNOME
Founation should give us their blessing. This will be about marketing and
motivation. Only the best of the best will be on this schedule, because the
whole thing will be useless if any binding breaks the schedule. Hopefully
this will encourage distros to package these bindings and promote them as
development platforms.

Bindings are fundamentally feature-based, so it's difficult to put them on a
time-based release schedule. So we need to be very careful - If your team is
on the schedule then you are committing to doing work.

Here are my suggestions for what this would mean. What do you think? It's
meant to be tough. Ask if something is not clear.


*** API freeze:

You freeze your API/ABI on the scheduled freeze date. This will probably be
around the same time as a final GNOME release - for instance March 8th 2003,
for GNOME 2.6.0:
http://www.gnome.org/start/2.5/

We will probably have an API freeze date and an ABI freeze date.


*** What does API/ABI Freeze mean?

Different languages have different concepts of API and some have no concept
of ABI. Here are some vague rules that we should all be able to understand:

If an application uses 2.6.0, installing 2.6.1 will not intentionally break
that already-installed application. As well as not breaking
already-installed applications, by changing ABI, you should not break
applications builds by changing API.

You may not add API in the 2.6 phase. You must wait until the next schedule
to add API. Although adding API does not break API/ABI, it does create
confusion. We want to tell people something simple like "2.6.x has this API.
Later versions of 2.6.x just have imlementation bugfixes, without API change
or addition.". Remember, it's not a problem if you have to wait to add API,
because you only have to wait <6 months until the next stable release.

You may break API/ABI in the next schedule (e.g. for GNOME 2.8.0). If you
break API/ABI, then your new vesions must be parallel-installable with the
older version. Again, the rule is "Don't break already-installed
applications."


*** API version numbers:

During the unstable development phase (before the API/ABI Freeze), you
should use odd numbers for your tarballs versions numbers, and for any
installed libraries. For the stable phase, you will use even numbers. _Try_
to use the same major numbers that GNOME uses.

You do not need to release new versions just because GNOME has a new
version. It's up to you when you do bugfix releases of your stable branches.
But we might announce a new GNOME Bindings release after a couple of months.
This will just have your latest stable releases, whatever they are. That's
what GNOME does for it's 2.x.1 and 2.x.2 releases.


*** Who gets in?

We only want bindings which can stick to the schedule, and we need to be
careful about being too optimistic. Previous history should be the best
indicator of the future here. I know that gtkmm/gnomemm can do it. I hope
that Python can do it, but I'm worried that it does not yet wrap GTK+ 2.2.
The C# bindings are very new, but they seem to have Ximian/Novell resources
behind them.

Also, the Perl bindings are showing lots of activity recently, and the Ada
bindings seem to be well-maintained. But I don't have the language-specific
knowledge to comment more on those myself. 

If you miss any freeze date or final release date by more than 2 weeks, you
will be kicked out of the schedule. It will be difficult, but not
impossible, to persuade us that you should be in the next release schedule.

Of course, anybody is free to follow the schedule even if they are not
officially on it. That binding would then have a very good chance of being
on the schedule next time.


*** What do you wrap?

You should _try_ to wrap the entire GNOME Developer Platform:
http://www.gnome.org/start/2.5/modules/

We should not expect everybody to wrap everything. For instance, Bonobo is
very difficult because it needs a CORBA binding. If you don't want to freeze
some of your GNOME-Platform bindings, such as for libbonobo*, you should say
that as early-as-possible, and package it separately to your official GNOME
binding package.

You do not need to put everything in one package. Modularity is good.

That does not include non-developer platform API such as libgnomeprint, or
libgda. It's great if you wrap those, but it needs to be done separately. So
if you currently bundle lots of stuff together in one package, you need to
put the extra stuff in a separate package.


*** Who will manage the schedule?

A small team needs to
- create the schedule
- send regular reminders of schedule dates
- repeat the above principles when necessary
- add, or remove bindings, from the schedules, based on their release
history.
- tell everyone about it.

This isn't actually much work, and doesn't require much skill. I suggest
that myself and/or James Henstridge should take charge of this. I would like
it to be at least 2 people. I would like to hear from volunteers. I think if
you do this well, you are likely to be on the GNOME release team eventually.

Here is some more information about the GNOME release team:
http://developer.gnome.org/dotplan/


[1]
http://www.gnomedesktop.org/article.php?thold=-1&mode=nested&order=0&sid=146
6

Murray Cumming
www.murrayc.com
murrayc usa net