On Sun, 2010-11-28 at 15:31 +0000, Colin Guthrie wrote: [...] > 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 might be missing something, but this scheme seems to preclude intermediate releases off the -dev branch (since the generated tarball will always have a $MAJOR.0 version). Or would that be solvable by pushing a $MAJOR.0_beta/_rc tag to git? I guess we /would/ want to make some pre-release(s) off the 1.0-dev before doing the final 1.0 release. Cheers, Arun
