D-Bus core due for a release?
hp at redhat.com
Wed May 16 11:41:29 PDT 2007
Simon McVittie wrote:
> We haven't had a release for over 5 months, and the patches are starting
> to build up... in particular, for Telepathy's Tubes technology
> (particularly on the OLPC) it would be useful to have a stable release
> that includes the message marshal/unmarshal support. dbus-1.1.0, anyone?
> (Or 1.0.3, if that's preferred... I'm slightly unclear on the versioning
> policy used.)
For major.minor.micro, odd minor = unstable/beta, even minor =
1.0.x = current stable branch, bugfixes only
1.1.x = pre-release snapshots for 1.2.x, here we put new features
1.2.x = future stable release (not yet made)
> I'm happy to do the release building/tagging/etc. if necessary.
That would be cool. There are instructions for this in HACKING iirc (if
there are gaps in the instructions, please get them filled in before
> Changes include:
> * D-Bus message <-> byte array marshalling/unmarshalling as public API
This would be a 1.2 feature. Right now I think it's the only new feature
pretty much that would really lead to a 1.2, so I'm not sure a 1.2
release is worth it yet; but doing a 1.1.x is worthwhile anyway.
The original 1.2 dream was win32 port and system bus activation, but
both of those are moving much too slowly to get to 1.2 anytime soon, afaik.
Maybe we should just do a 1.2 then with what we have, or at least plan
to do one soon.
Either way the first step is a 1.1.x beta, so if you want to do that it
would start us down the road.
> * allow eavesdropping on method replies on the session bus, making
> dbus-monitor a substantially better debug tool
> * add daemondir to .pc file
These should both be backported to 1.0.x if it was not done at commit
time (people keep failing to do this, bad people), and we should do a
1.0.x with these in it.
> * lots of Win32 stuff including a CMake build system
This is 1.1.x only
> * possibly the user database (it's unclear whether this made it into 1.0.2)
Not sure I remember the current state here, but I thought there was a
patch that needed some performance testing before we put it in.
> * spec clarifications regarding the reserved local path/interface
> * rejection of zero-length bus addresses
> * increased resource limits
> * fix fd.o #10781 (invalid fd check)
These should all be in a 1.0.x release so would need backporting if they
were not committed to both branches.
I'm sure "backporting" is just a matter of checking out both branches,
doing the diff -rwhatever -rwhatever from HEAD and committing the
resulting patch to 1.0.x, the two trees are similar enough there should
not really be much patch massaging or actual work in order to backport.
diffing the ChangeLog between the two branches may be enough to show
which patches were not applied to stable that should have been.
If you spend a lot of time on this feel free to flame people about how
in the future they should commit to both branches :-P
It might be worth doing a 1.0.x even if you don't have time to backport
all the fixes that should be, on the 'something is better than nothing'
More information about the dbus