D-Bus core due for a release?

[Havoc Pennington]

Hi,

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 = 
stable/frozen.

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 
acting).

> Changes include:
> 
> Features:
> * 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.

> Fixes:
> * 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' 
principle.

Havoc