On Sat, 2012-01-21 at 01:07 +0100, Lennart Poettering wrote: > On Fri, 20.01.12 17:08, Ted Gould (ted gould cx) wrote: > > > I already maintain a ton of stuff, and I try to keep maintenance burden > > > and bureaucracy small for myself. Hence the Wiki, and not a complex > > > standards process and a git repo. All API versioning we need should be > > > done within the D-Bus interface itself (where the right place is for it > > > anyway) and all documentation versioning by using the history > > > functionality of the wiki. > > > > I guess that I don't see that as adequate (hence why I suggested > > something more formal). > > What could be more formal than a machine readable interface definition > as it is included in the Wiki page? I was more referring to formality of process rather than how the interface is specified. I imagine there won't be many versions of the interfaces, but there will be of the tools (like systemd) that implement them. > > One way that I had thought this could work on the Debian packaging > > side of things would be using the Requires/Provides labels in the > > package. So then something like systemd could provide > > "freedesktop-system-interfaces-45" and GNOME could require that. > > Right. What could be a better identifier for an interface and its > version, than, well, the interface name which includes the version? > i.e. use "org.freedesktop.timedate1" for that. And if you don't like the > dots, then replace them by dashes or so, for use by your package > manager. > > > There could also be other providers and users who wanted to switch > > would then get their choice. Pulling the version number from the wiki > > for all the different interfaces would make that complex and > > burdensome to maintain for the packagers involved. Which is why I > > suggested something with a more stable and uniform release process. > > I am not sure how better to achieve uniformity and stability than by > by using the version information that is embedded in the interface > definition itself? > > I am sorry, but you explicitly *don't* want another level of naming or > versioning here, because then you'd have to maintain multiple versioning > streams for the same stuff, and that'd suck. So, let's use a simple use case. For what ever reason, it is decided that one of the interfaces needs a new property. I'm guessing that you'd expect that the interface name wouldn't change as it would be backwards compatible. Now GNOME Control Center comes along and needs that new property to implement their interface. How should G-C-C express that requirement? --Ted
Attachment:
signature.asc
Description: This is a digitally signed message part