RE: A GNOME Bindings release set?
- From: Murray Cumming Comneon com
- To: language-bindings gnome org
- Cc: release-team gnome org
- Subject: RE: A GNOME Bindings release set?
- Date: Tue, 2 Dec 2003 17:58:55 +0100
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
murrayc usa net
> -----Original Message-----
> From: release-team-admin gnome org
> [mailto:release-team-admin gnome org] On Behalf Of
> Murray Cumming Comneon com
> Sent: Montag, 24. November 2003 11:41
> To: language-bindings gnome org
> Cc: release-team gnome org
> 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
murrayc usa net
_______________________________________________
release-team mailing list
release-team gnome org http://mail.gnome.org/mailman/listinfo/release-team
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]