[pulseaudio-discuss] [ANNOUNCE] New Version Naming Scheme
arun.raghavan at collabora.co.uk
Sun Nov 28 22:19:00 PST 2010
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
> 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.
More information about the pulseaudio-discuss