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

[Colin Guthrie]

'Twas brillig, and Colin Guthrie at 29/11/10 09:41 did gyre and gimble:
> '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).

> 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.

I've now implemented this capability in git-version-gen in master.

I also forgot to push the v1.0-dev tag on master with the previous
changes, so apologies for messing that up. If you pull from master now
you should get a new tag and your version should be set accordingly.
Obviously all my testing was on my clone which had the tag in it so all
my tests and such like still stand.

Cheers

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