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

[Tanu Kaskinen]

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.

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.

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.

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?

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

-- 
Tanu Kaskinen