[pulseaudio-discuss] Can I push a tag on master to set the version?

Colin Guthrie gmane at colin.guthr.ie
Sun Sep 26 07:01:45 PDT 2010

'Twas brillig, and Tanu Kaskinen at 25/09/10 18:09 did gyre and gimble:
> On Sat, 2010-09-25 at 12:08 +0100, Colin Guthrie wrote:
>> Hi,
>> I've had a few people recently ask me about the version of git master.
>> As it's based on git tags, I'd like to push a tag to git master called
>> e.g. "v0.10.0-pre1" or "v0.9.23-pre1" (reserving v0.9.22 for stable-queue)
>> This will "fix" the version when building from git master. That said if
>> we do make a 0.9.22 from stable-queue and then release another from s-q,
>> before master is truly stabilised, then we would likely want to delete
>> any tags on master that are confusing or incorrect.
>> We can also talk about rebasing and other resolutions here, but if
>> possible that should be avoided.
> Like you say yourself, tagging master with v0.9.23-pre1 would cause a
> conflict if yet another bugfix release would be made after v0.9.22
> before making a new feature release. So I suggest you don't use that.

Yeah, fair enough.

> I'm not sure I like v0.10.0-pre1 either. The problem with it is that
> such tag wouldn't point to any actual release. Consider the situation
> when v0.10.0 would be released. Now when new stuff is committed to
> master, the versioning logic would have to be fixed again by creating
> tag v0.11.0-pre1. It would mean that the very next commit after v0.10.0
> would be tagged with v0.11.0-pre1. That seems a bit "funny" to me. But
> maybe it's needed - I don't have any better ideas. Actually, unless
> better suggestions pop up, I encourage you to go ahead and push
> v0.10.0-pre1.

Perhaps rather than pre1 (which tends to be used by some projects as
part of their release cycle - e.g. pre -> alpha -> beta -> rc -> final),
perhaps we could just tag the first commit after a release with
"v0.10.0-devel" that way the name -devel is in there and it doesn't
imply an official "release" tag?

That way after the tagged release, we do a devel tag and work from that.
It's maybe not 100% perfect, but it would fit in with the
git-version-gen script.

The other option is to not use git-version-gen....

> By the way, is there some implied new logic behind the 0.10.0 version
> number? As long as I've been involved, only Z of X.Y.Z has been used to
> differentiate releases, regardless of whether they have been feature or
> bugfix releases. Tagging master with 0.10.0-pre1 looks like you may want
> feature releases to increment Y and bug fix releases to increment Z. If
> that's what you're thinking, I give my full support.

Yeah that was what I was thinking. See my previous message on the topic

I've had a few folk from the downstream community support this. As a
short summary it kinda stems from the current set of releases coming
from 0.9.19 as a base with master diverging away for development stuff.

So what I was thinking was that the current stable-queue branch becomes
the 0.9.x branch and master (based on 0.9.19 but with all the fixes in
stable-queue too) becomes main branch towards the 0.10.0 release.

> Related to this discussion, I have some questions about
> <http://pulseaudio.org/wiki/GitBranches>.
> The bugfix release procedure is unclear to me: "if it is a bugfix
> release he merges the stable-queue and the last xxx-stable branch (plus
> master-tx if it didn't deviate too much) and releases this." What is
> merged into what? Stable-queue and master-tx into xxx-stable? And after
> that is done, xxx-stable is tagged and released?
> Why are there two branches with seemingly similar purpose (i.e.
> collecting patches for the next stable release)? The only difference
> seems to be that stable-queue accumulates small features, and xxx-stable
> accumulates bug fixes. Is this distinction important?

I think we've ultimately diverged from that and thus it should probably
be updated to reflect this.

Currently stable-queue really just represents some "fixes on top of the
last stable release". I think this is fairly sensible, but with the
current versioning scheme it does not make a "bugfix release" all that
simple (due to versions of what is represented by the master is based on
it's last tag.

So I think if we agree that master will be the branch for the next Y+1
release, then when we do a release the branch 0.Y can be created which
will effectively become the "stable-queue" for the 0.Y series of
releases with the bugfix releases (0.Y.1, 0.Y.2 etc.) performed directly
off that branch (with patches either cherry picked to or from master as

I personally think this approach reflects what our git repo has
ultimately become and would work for most people. The only thing to
worry about is the "official" status a Y version bump would perhaps
indicate to people not immediately involved in upstream. I think we can
deal with that tho'.

> Maybe it is - distros may want to only integrate bug fixes between
> upstream releases, and leave the small feature additions to the time
> when a new upstream release is made. Having a separate branch for bug
> fixes only makes the distribution maintainers' life easier. But then
> when a new bug fix release is done and stable queue is merged into
> xxx-stable, that separation is broken.

I think we can use our general infinitive here to be honest. Small
feature additions are IMO OK in a "stable" series. e.g. adding new mixer
profiles for some hardware and such is arguably a new feature, but it's
something we'd certainly want to include in a rollup release. I think we
just make "sensible" decisions as to what goes into the bugfix releases.

> This is probably not a big deal,
> but this is easily avoided by creating the next stable branch, (let's
> call it xxy-stable) from xxx-stable before doing any merging, and then
> merging stable-queue and master-tx into xxy-stable and making the
> release from xxy-stable. Maybe that was already the idea, but the wiki
> page is unclear on this.
> Lately only stable-queue has been used, not xxx-stable. If the plan is
> to continue with that strategy, then the wiki page should be updated.

If there is general consensus on the version numbers I'll update the
wiki. I want to do a 0.9.22 release from current stable-queue ASAP, but
to do that I want to get a clear picture as to what we'll be doing
versions wise.

Hopefully Lennart will join back in soon now Fedora is frozen and give
his casting vote on the topic.



Colin Guthrie

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