Sex, 2006-01-20 às 09:10 -0700, Elijah Newren escreveu: > On 1/20/06, Johan Dahlin <johan gnome org> wrote: > > > Well, no library in the desktop can be relied upon to remain API or > > > ABI stable; that's the reason they are in the desktop. The difference > > > with this lib, _if_ I remember correctly, is that those other libs in > > > the desktop were meant to be used by whoever wanted to use them, > > > whereas libmetacity-private was expected to not be used by anything > > > other than control-center (with the implication that if we make any > > > changes that breaks anything other than the control center, we just > > > don't care and won't consider it a bug). > > > > Is it not similar to wnck, which mostly the panel uses? > > Similar, but not the same. Havoc intended libwnck to be used by other > apps besides just the panel. And other apps do use it. From the > README: > > "libwnck isn't supported in the devel platform, which means OS vendors won't > guarantee the API/ABI long-term, but authors of open source apps > should feel free to use libwnck as users can always recompile against > a new version. (And the API/ABI has historically changed very little, > I'm not changing it gratuitously or without soname increments.)" > > While libwnck doesn't have API/ABI requirements from the release set > it is in, we agreed a release cycle or two back to not break API/ABI > after feature freeze. Also, when making API/ABI changes that breaks > something, or adding API to libwnck that certain modules need to use, > I make a best effort (which is sometimes lacking, in particular I just > realized I've always forgotten to notify the bindings people -- which > is perhaps why you see it as no different) to at least notify apps > that I know are affected and often also provide patches. > > I wouldn't bother notifying anyone if I broke ABI of > libmetacity-private (other than control-center), even if it was during > a micro point release during the stable cycle. This already happened once with wnck, with nasty results: http://www.daa.com.au/pipermail/pygtk/2006-January/011660.html But we understand the limitations of API guarantees and live with it. > > However... > > > To me the name metacity-private is just another way of saying > > it's an unstable library and don't complain to us if we break your > > application. > > If you're fine with that, feel free to go ahead. :) I do have to say > that it does sound like a very cool use you have for > libmetacity-private. And, you're probably unlikely to get any > breakage since no one (least of all me) seems to be interested in > working on anything theme related in Metacity right now. It's just > that we're not going to make any guarantees. So I've finally released the split g-p-e/g-p-d packages, leaving metacity in g-p-e and untouched. I almost thought about renaming to metacity.private, but it's ugly, and I thought this discussion had died out with no much concern. At the time I received this email, I had already uploaded the packages. I hope this will not cause much concern, but I guess renaming the module or issuing a warning during import is still a viable option. Regards. -- Gustavo J. A. M. Carneiro <gjc inescporto pt> <gustavo users sourceforge net> The universe is always one step beyond logic.
Attachment:
signature.asc
Description: Esta =?ISO-8859-1?Q?=E9?= uma parte de mensagem assinada digitalmente