[pulseaudio-discuss] Version numbers & rollup releases

[Colin Guthrie]

Hi,

This has been discussed before but it's becoming an issue now.

There are some bugs that need patches and work around in client
applications which actually check that the fix is in PA itself to take
appropriate action (a recent example would be knowing that PA has XCB
support for client side X11 interaction vs. Xlib and taking appropriate
action to call XInitThreads() or not).

In a recent case VLCs pulse output had to call XInitThreads work around
bug 799 which is a valid thing to do (it's a very convoluted situation
that means that pushing this thing up to the application layer is
awkward as the whole PA layer in libvlc is itself just an option - the
app just produces sound - this is further complicated by any alsa
clients going via alsa-pulse layer etc. Obviously libpulse using XCB is
the right solution here, but we need to know in VLC whether or not to
call XInitThreads (because libpulse is using Xlib), or not (because it's
now using XCB)

Anyway, obviously the clearest way to do this is a simple
PA_VERSION_CHECK() call in the client side code. For that we can't just
apply a patch to stable-queue; we need a release.


Now on to the next point: More frequent releases. I know that Lennart
doesn't like doing releases, but I think I speak for everyone of us
triaging bugs and working on patches for the stable-queue branch would
prefer to have more interim releases (especially in the current case
where 0.9.22 has been so long in the kitchen due to systemd distractions!).

I'm happy to do the necessary work of tarball creation and announcements
but I think we need a clearer policy on version numbers to go along with
such a scheme.

I'm therefore going to propose something:

Major changes will result in a PA_MINOR bump.

For as long as I've been involved in PA (which is quite a while now)
it's only ever had PA_MICRO bumps... I'm not sure if there is a
particular reason for it (perhaps 9 is Lennart's lucky number?), but I
don't see any real reason not to push that up to 10 and beyond (for
clarity I don't think it's relevant to consider any kind of PA_MAJOR
change - it should be reserved for then the library ABI needs to break).


So, in short, I'd like to take the following actions:

1. Rename the milestone 0.9.22 to 0.10.0. The current git master should
ultimately become 0.10.0 (with all it's DBUS funkiness).
2. Tag stable-queue as 0.9.22 and release a tarball[1]


Lennart: As always you are in charge, but keeping a track on things is
so much easier if I don't have to explain the fact that there are 170+
patches to apply on top of the last stable release.

If you are happy to adopt this numbering approach, I'll take the extra
load that results from doing more interim releases.

I know that distro policy means that version bumps in packages for
stable distros are generally frowned upon by distro release managers,
but I get the feeling that this is slightly more relaxed these days (I
know it is in Mandriva) if the upstream project is quite clear about
their recommendations and their versioning scheme.

I mean if 0.10.x is basically "the official, upstream recommended
version of the 0.10 series" then distros can rest easy in updating
0.10.0 to 0.10.1 in a stable distro. This wont always work if the distro
is too strict but it's still a generally sensible approach to versioning.

So, what do you think?

Col

1. Only after the either David's or Pierre's patch for fixing tsched=0
mode is merged into s-q tho' :D


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]