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