[pulseaudio-discuss] [ANNOUNCE] New Version Naming Scheme

Colin Guthrie gmane at colin.guthr.ie
Sun Nov 28 07:31:39 PST 2010


Hi All,

As you know I've been angling for some kind of solid way forward with
version numbers for a while so this email is basically a description of
what has been done about this and how we'll move forward.

As some of you know, the version is automatically grabbed from the git
tags when building. This can be convenient but also a pain at times. So
this email will outline how I propose to handle this and when ACKed or
thrashed out, I'll put the summary on the wiki so we can reference it
(there is a page for this currently but "what we end up doing" has
diverged from that a bit of late - I personally don't get too stressed
out about these kind of divergences as we don't put rules in place to
make things more awkward for ourselves, so if it turns out they are not
perfectly suited to us, we can change them :D)

Anyway, the whole concept of 0. prefixes is a bit of a paint. There is,
in general no real concept or criteria for what would allow us to
release a "1.0" version and there seems to be far too much emphasis
placed on this "milestone" but people outside of projects. So the 0.
prefix is something that we're not really all that keen on preserving,
purely from the perspective of it puts pressure on there actually being
a "1.0" milestone. As well all know, software is evolutionary, and
likely PA will continue in many guises for some time to come. Staying at
0.x.y forever is not really beneficial to anyone.

Lennart originally favoured just a single version, but as we discussed
this scheme, I argued that it would prevent us doing what we are doing
right now with the stable-queue releases (0.9.20 through 0.9.22) which
diverged from the master development tree after the 0.9.19 release.

So if we only had a single version number, the same problems would be
apparent with our current version conundrum. As a compromise for
simplifying things and for getting a sensible version tag pushed to
master, we decided to adopt a major.minor version scheme.

By following this principle, this means that master will eventually
become our v1.0.

This means that master will be tagged as "v1.0-dev" version soon and the
necessary changes to the build system will be made to suit this. To keep
backwards compatibility, PA_MICRO will still be defined in version.h,
but will always be 0.


When a new major release is rolled, the tag is pushed to the developers
local git repository and the tarballs are generated (the tag needs to be
in place for this to work). When all is tested, the tag will be pushed
and the tarballs published. A new branch will also be created called
"$MAJOR.x-stable" (the name is up for discussion, but I think it's
sensible).

Whenever the next commit is made to master, it will be tagged as
"$(($MAJOR+1)).0-dev". This allows the correct version number to be
represented in builds made from the git tree. Likewise, when a commit is
pushed to "$MAJOR.x-stable" branch it will be tagged as "v$MAJOR.1-dev",
again to indicate the version more accurately in builds. If/when we
release a bugfix update from the "$MAJOR.x-stable" branch, then we will
tag it as "v$MAJOR.1" with the next commit after release getting the
"v$MAJOR.2-dev" tag and so on for any bugfix releases we make.

So with the above policy, after each official version tags, the next
commit should always have a new version tag with the -dev suffix.

I believe this method of working will be quite clear and also follows
quite closely the general approach we had with stable-queue, but with a
simplified naming scheme and version tag policy on top.

I hope you all agree, but if there are any major issues, just shout and
we can discuss :)

I'll wait a couple days to push the changes I have that implement the
above, just in case any glaringly obvious brown-paper-bag moments are
spotted by others :)

Col







-- 

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

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]




More information about the pulseaudio-discuss mailing list