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

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
here:
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/7296

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

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.

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/]