Hi All, As you know I've been angling for some kind of solid way forward with version numbers for a while so this email is basically a description of what has been done about this and how we'll move forward. As some of you know, the version is automatically grabbed from the git tags when building. This can be convenient but also a pain at times. So this email will outline how I propose to handle this and when ACKed or thrashed out, I'll put the summary on the wiki so we can reference it (there is a page for this currently but "what we end up doing" has diverged from that a bit of late - I personally don't get too stressed out about these kind of divergences as we don't put rules in place to make things more awkward for ourselves, so if it turns out they are not perfectly suited to us, we can change them :D) Anyway, the whole concept of 0. prefixes is a bit of a paint. There is, in general no real concept or criteria for what would allow us to release a "1.0" version and there seems to be far too much emphasis placed on this "milestone" but people outside of projects. So the 0. prefix is something that we're not really all that keen on preserving, purely from the perspective of it puts pressure on there actually being a "1.0" milestone. As well all know, software is evolutionary, and likely PA will continue in many guises for some time to come. Staying at 0.x.y forever is not really beneficial to anyone. Lennart originally favoured just a single version, but as we discussed this scheme, I argued that it would prevent us doing what we are doing right now with the stable-queue releases (0.9.20 through 0.9.22) which diverged from the master development tree after the 0.9.19 release. So if we only had a single version number, the same problems would be apparent with our current version conundrum. As a compromise for simplifying things and for getting a sensible version tag pushed to master, we decided to adopt a major.minor version scheme. By following this principle, this means that master will eventually become our v1.0. This means that master will be tagged as "v1.0-dev" version soon and the necessary changes to the build system will be made to suit this. To keep backwards compatibility, PA_MICRO will still be defined in version.h, but will always be 0. When a new major release is rolled, the tag is pushed to the developers local git repository and the tarballs are generated (the tag needs to be in place for this to work). When all is tested, the tag will be pushed and the tarballs published. A new branch will also be created called "$MAJOR.x-stable" (the name is up for discussion, but I think it's sensible). Whenever the next commit is made to master, it will be tagged as "$(($MAJOR+1)).0-dev". This allows the correct version number to be represented in builds made from the git tree. Likewise, when a commit is pushed to "$MAJOR.x-stable" branch it will be tagged as "v$MAJOR.1-dev", again to indicate the version more accurately in builds. If/when we release a bugfix update from the "$MAJOR.x-stable" branch, then we will tag it as "v$MAJOR.1" with the next commit after release getting the "v$MAJOR.2-dev" tag and so on for any bugfix releases we make. So with the above policy, after each official version tags, the next commit should always have a new version tag with the -dev suffix. I believe this method of working will be quite clear and also follows quite closely the general approach we had with stable-queue, but with a simplified naming scheme and version tag policy on top. I hope you all agree, but if there are any major issues, just shout and we can discuss :) I'll wait a couple days to push the changes I have that implement the above, just in case any glaringly obvious brown-paper-bag moments are spotted by others :) 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/]
