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