| Subject: | Could it make v${last_release}_${serial_number} versions for developer releases? |
Hi again,
The aim of this feature request is to generate version numbers that CPAN
will recognise as developer releases. As I understand it, this means
containing an "_%d" suffix after the version number of the release it is
following.
This feature request might be unnecessary, if there is a better way to
do it that I didn't think of. Please let me know if you would rather
discuss it on a mailing list.
What I thought I wanted when I picked up DZP:G:DescribeVersion was
something more similar to the hack I made for PerlUnit (from which you
are welcome to take Perl5-licenced code if appropriate),
http://perlunit.git.sourceforge.net/git/gitweb.cgi?p=perlunit/perlunit;a=history;f=inc
The algorithm I settled on there is, as I remember from a couple of
months ago,
0) defer to existing $VERSION in the headlining module, if .git/ is absent.
The tardist has the versions hardwired in.
I am spared this messiness under Dist::Zilla.
1) do we have --exact-match --match "v[0-9].*" (oh, that should be
"v[0-9]*") on HEAD?
Use that exactly, it is probably a manual release tag or a rebuild
of a release.
This also detects a dirty working copy and fails. If we're building
for a release tag, build exactly what is tagged. Unfortunately, this
needs some other git call to update the index or there can be false
positive "dirty" marks in the describe output.
I know that DZP:Git::Check can do that for me now. For release
tags, I would probably prefer to trap it early; but for dev tags it
makes sense to let it run dirty.
2) is a repeat of 1) but with --match "dev[0-9]", to do the same for
old dev builds.
However, if the working copy were allowed to be dirty the version
number should be different. There may be a following DZP:Git::Commit
... I'm not sure how this should interact.
3) otherwise, we are making a dev release.
Versions are made with sprintf("%s%s_%04d", $prefix, $last_release,
$serial_number) so that CPAN recognises it as a developer build.
I use $prefix="dev" for git-tag, which makes subsequent git-describe
calls easier. I don't know another way to make git-describe ignore the
dev releases completely, and I wanted dev tags to be always relative to
a non-dev release.
I tried some ways to construct $serial_number. It can't be solely
the commit count since the production release tag, because rebases and
merges make this unlikely to be monotonic. I settled on making it
composite with $serial_number = sprintf("%02d%02d", $one_more,
$commit_count); $one_more is found by listing existing tags =~
m{^(?:de)?v${last_release}_(\d{2})} and taking max(1+$1); $commit_count
becomes redundant but possibly still informative.
After this, and because I insisted on having a clean working copy, I
applied the new dev tag immediately after generating the version. This
is inconvenient because I couldn't "perl Makefile.PL" on a dirty tree,
and it litters dev tags on things I had rebased away.
I don't supply --tags to git-describe; I wanted to see only annotated
tags. I forget why.
Hmm, having written all this in the context of DZP:G:DV, I'm wondering
if I should have filed it under Git::DescribeVersion instead? It might
suit me to use that as a build dependency for PerlUnit, rather that drag
it forward to Dist::Zilla. It tries to support ancient Perls...
I hope this explanation of how I made version numbers is useful, and I
would appreciate having something similar in (DZP:)G:DV. I realise you
might not want to do it, or have time to do it any time soon. I would
appreciate some guidance on what you might be happy to merge into your
tree, in the case that I have time to fork & hack.
Thanks,
--
Matthew