Bug #71626 for Dist-Zilla-Plugin-Git-DescribeVersion: Strange version numbers, on second build-release-tag cycle

Wed Oct 12 06:08:38 2011 mca1001 [...] users.sourceforge.net - Ticket created

Subject:

Strange version numbers, on second build-release-tag cycle

Hi Randy, I'm not sure whether this is a problem with my dist.ini, or my expectations of iterating DZP:G:DescribeVersion and DZP:G:Tag, or a proper bug; but it does carry a feature request with some example code. What I'm seeing with https://github.com/mca-wtsi/App-MediaWiki2Git is a progression of version numbers that does this, v0.01 manual tag (two commits) v0.001002 automatic DZP:G:Tag (four commits) v0.1002004 next build... I balk here. I can see that adding a "004" on the end of .001002 makes sense by the rule that made .001002; but it's not a sustainable pattern for useful version numbers! I haven't figured out where the leading 0's are going (between "v0." and "1"), but this may be because I haven't read L<version> enough. I was using the default configuration, so I expected that multiple passes of build-release-tag would work in a fairly standard way. Would this settle down if I had started from some version other that v0.01? Did I need to change the match and regexp configuration? I'll write another ticket for the feature request, because that part is getting too long. (One issue, one ticket.) Thanks for your help, -- Matthew

Wed Oct 12 06:33:51 2011 mca1001 [...] users.sourceforge.net - Member ticket #71628 added

Fri Mar 23 13:28:44 2012 RWSTAUNER [...] cpan.org - Correspondence added

I'm dreadfully sorry for not replying sooner... My inbox fills up fast and I forget things. I implemented your other request on the main module (https://rt.cpan.org/Ticket/Display.html?id=71622) when you made these tickets, but then forgot about the rest. Anyway, I think I understand the issues you were seeing. G:DV was not designed to be combined with DZP:G:Tag. G:DV was designed to append the final (third) part onto a partial (two-part) version. That should be explained in the documentation but probably isn't. The way I was using it at the time was to tag the repo with two numbers when I felt something "big" had changed... (for example, from v3.4 to v3.5). Then I'd let this module fill in the third number (v3.4.1, v3.5.11). So when this module created the version, :Tag saved it (which wasn't expected by this module), and so the next time G:DV ran it appended another piece. As for the "missing zeroes" from v0.001002 and v0.1002004... D::GV expects to find the first two parts, and append the third. When DZP:G:Tag saved your tag with the "three" parts, G::DV (probably incorrectly) parsed it as a 3-part version with a lot of digits in the second part and version.pm normalized out the leading zeroes: *$ perl -Mversion -le 'print version->parse($_)->numify for @ARGV' v0.001 v0.001.002 v0.001002 v0.001002.004 0.001000 0.001002 0.1002000 0.1002004 So G::DV needs to document clearly that it expects the first 2 parts of a version and appends the third. Additionally it should probably specifically state that it is not meant to be combined with DZP:G:Tag (but rather the 'two parts' should be tagged manually). Nowadays I use DZP:G:NextVersion (and :Tag) for my cpan projects and I only use G:DV for my $work projects for which I don't do formal "releases", I just want every commit to bump the version so that I can tell when one of my 80 machines has a different version than the others.

Fri Mar 23 13:28:46 2012 The RT System itself - Status changed from 'new' to 'open'

Fri Mar 23 13:42:35 2012 RWSTAUNER [...] cpan.org - Correspondence added

I looked at https://github.com/mca-wtsi/App-MediaWiki2Git/commit/d049781134610791b7d9e3465892ae952c668f15 I don't think that's going to give you the correct count... I think that that's going to grab the last tag (v0.001002), take the first part (0.001), and then append the number of commits since that last tag. $ git tag v0.001002 v0.01 $ git describe-version 0.1002004 $ git describe-version --version-regexp='v(\d\.\d{1,3})' 0.001004 The 'version_regexp' was intended to grab the 'whole' version out of a tag with other characters... i think that only capturing part of the version will likely lead to more confusion. I understand that you were trying to work around the confusion caused by the combination of DV with Tag and setting version_regexp might have looked like it solved that issue, but I think it will get the count wrong sooner than later.

Sat Mar 24 11:12:27 2012 mca1001 [...] users.sourceforge.net - Correspondence added

Subject:	Re: [rt.cpan.org #71626] Strange version numbers, on second build-release-tag cycle
Date:	Sat, 24 Mar 2012 15:12:15 +0000
To:	Randy Stauner via RT <bug-Dist-Zilla-Plugin-Git-DescribeVersion [...] rt.cpan.org>
From:	Matthew Astley <mca1001 [...] users.sourceforge.net>

On Fri, Mar 23, 2012 at 01:28:45PM -0400, Randy Stauner via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=71626 > > > I'm dreadfully sorry for not replying sooner...

No worries. I could've forked and used a local copy but I chose to set the version manually on the few releases I made. I would still like a version generator that works a bit like the current Test::Unit one. Thank you for your offer (RT#71628) of comaint. Some moons may pass before I get hacking time for this. 8-( Show quoted text

> My inbox fills up fast and I forget things.

If you find a good solution, kindly let the rest of us know! Show quoted text

> G:DV was designed to append the final (third) part onto a partial > (two-part) version. [...] So when this module created the version, > :Tag saved it (which wasn't expected by this module), and so the > next time G:DV ran it appended another piece.

Thanks for the explanation. Show quoted text

> So G::DV needs to document clearly that it expects the first 2 parts > of a version and appends the third. > > Additionally it should probably specifically state that it is not > meant to be combined with DZP:G:Tag (but rather the 'two parts' > should be tagged manually).

I forked & pushed, just enough to clarify the current situation. Please amend as necessary. Show quoted text

> Nowadays I use DZP:G:NextVersion (and :Tag) for my cpan projects > and I only use G:DV for my $work projects for which I don't do formal > "releases", > I just want every commit to bump the version so that I can tell when one > of my 80 machines has a different version than the others.

That makes sense. There must be many modes of doing (semi-)automated version numbering from Git into Perl. I would like to see some enumerated, described and recommended but if I were to start it's not clear where to put them. Do you have suggestions? On Fri, Mar 23, 2012 at 01:42:36PM -0400, Randy Stauner via RT wrote: Show quoted text

> I looked at > https://github.com/mca-wtsi/App-MediaWiki2Git/commit/d049781134610791b7d9e3465892ae952c668f15 > > I don't think that's going to give you the correct count...

It doesn't, I passed in V=mumble and then left the release in a "works for me" state. For me, the patch https://github.com/mca-wtsi/Git-DescribeVersion/commit/b9c8a4da closes this ticket as just a POD bug. hth, -- Matthew

Tue Aug 21 23:31:17 2012 RWSTAUNER [...] cpan.org - Correspondence added

Finally got around to releasing updates to both dists. Thanks for the help in clarifying those.

Tue Aug 21 23:31:17 2012 RWSTAUNER [...] cpan.org - Status changed from 'open' to 'resolved'