We have four types of tags in libvirt.git right now:
* vX.Y.Z: we have one of these per release, starting with v0.1.0
from April 2006 and going all the way to v5.2.0 from April 2019
(but see below). Most of them[1] are PGP-signed.
* LIBVIR(T)_X_Y_Z: these point to the same commit as the ones
above, but the last one we created is for v0.6.5 from July 2009;
not a single one is PGP-signed.
* CVE-YYYY-*: these point to the commit fixing the corresponding
vulnerability. We seem to have stopped creating them in 2017,
even though we definitely have had to deal with CVEs since ;)
* LIBXEN_FIRST_COMMIT: one-of-a-kind tag pointing to the second
ever (!) libvirt (!) commit. Of course the project was still
called libxen back then, but this is the only surviving tag to
reference the old name.
Interestingly[2] enough, a few releases seem to have partially or
completely slipped through the cracks:
version commit tag tarball
--------- -------------- ----- ---------
v0.1.2 | 567b42ce6a07 | no | no
v0.1.5 | 786e029cd743 | no | yes
v0.4.0 | 6cb028991705 | no | yes
v0.4.3 | 7db4c905d745 | no | yes
v0.4.5 | 9d3d43436eac | no | yes
Note that I stopped checking at v0.6.5, so there might actually be
more.
Anyway, since the LIBVIR(T)_X_Y_Z tags are a strict subset of the
vX.Y.Z tags, and we have abandoned that naming scheme a decade ago,
all they're doing right now is clutter the output of 'git tag' and I
would suggest getting rid of them; same goes for that lonely, lonely
LIBXEN_FIRST_COMMIT tag, which serves no real purpose other than
reminding us that the project was named differently for, like, an
entire month.
As for the missing release commits, I see no harm in creating them
retroactively for completeness' sake, but if nobody can be bothered
doing that I'll also fully understand :)
The CVE tags... I really don't have an opinion there.
Thoughts?
[1] Though not all of them: I'm pointing my finger at you, Cole! :P
[2] Well, to me at least.
--
Andrea Bolognani / Red Hat / Virtualization