[pulseaudio-discuss] [ANNOUNCE] New Version Naming Scheme

Colin Guthrie gmane at colin.guthr.ie
Mon Nov 29 01:41:34 PST 2010


'Twas brillig, and Colin Guthrie at 28/11/10 15:31 did gyre and gimble:
> 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 thought of a problem with this. It will mean that this first commit
will not be included in the annotated tag (i.e. all changes since the
last tag).

This annotated tag will be all kinds of messed up for the v1.0 release
anyway but for future releases it would be nice to keep things clean.

It should be easy enough to tag a release commit with both v1.0 and
v2.0-dev. The trick will be making git-version-gen ignore v2.0-dev when
it's looking at the exact same ref as v1.0, which shouldn't be too tricky.

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




More information about the pulseaudio-discuss mailing list