RE: A GNOME Bindings release set?

So, is anybody going to take part in this? I would like to get moving
quickly because it is already quite late in the GNOME release schedule. That
means getting some test tarballs released in a couple of weeks time.

I know that gtkmm can do it, but it would be silly with out at least 2
bindings.

Murray Cumming
www.murrayc.com
[email protected]

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of 
> [email protected]
> Sent: Montag, 24. November 2003 11:41
> To: [email protected]
> Cc: [email protected]
> Subject: A GNOME Bindings release set?
> 
> 
> 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&o
rder=0&sid=146
6

Murray Cumming
www.murrayc.com
[email protected]
_______________________________________________
release-team mailing list
[email protected] http://mail.gnome.org/mailman/listinfo/release-team
_______________________________________________
language-bindings mailing list  [email protected]
http://mail.gnome.org/mailman/listinfo/language-bindings