Mailinglist Archive: opensuse-packaging (155 mails)

< Previous Next >
Re: [opensuse-packaging] Re: Proper version scheme for packages from git, hg, svn, ...
  • From: Adam Spiers <aspiers@xxxxxxxx>
  • Date: Sat, 11 Jan 2014 13:53:21 +0000
  • Message-id: <20140111135320.GD13009@pacific.linksys.moosehall>
Jan Engelhardt (jengelh@xxxxxxx) wrote:

On Saturday 2014-01-11 12:56, Adam Spiers wrote:

No need to grab the base separately, just use --long:

Grabbing the base separately is necessary to catch the
(braindead) case that you have a tag called "v3.4-5-g1234567".
If you just run git describe, you therefore could not determine
whether your current HEAD is (v3.4-5-g1234567)-0-g9876543 or
(v3.4)-5-g1234567.

Like I said, --long solves that case, because it *always* outputs the
long format, so there is no ambiguity.

For example, if a non-release tag is introduced into the
repository, how would you ensure that the tag-offset doesn't suddenly
drop back to zero?

git describe --match=

One would at least hope you name your release tags reasonably unique
that they are programmatically distinguishable from nonrel tags (that
would also be worthwhile from a human perspective).

So to be clear, you are suggesting a generally applicable technical
solution based on hope?

I am suggesting that people not turn off their brains.

You don't just make a non-release tag and give it a name like a
release tag.

OK, so let's assume I have a bunch of tags like:

v1.0.1
v1.0.2

etc. We are looking for a programmatic solution which can be automated by
tools such as tar_scm. You are presumably suggesting to use something like

git describe --match='v[0-9]*.[0-9]'

right? But there is no pattern which for release tags, and
non-release tags, therefore you are introducing the requirement for a
custom glob per project. And this glob is necessarily brittle,
because very often the person maintaining the upstream repository
containing the tags is different to the person maintaining the
downstream package, and will have zero awareness that someone else is
hoping they will ensure that a) all their release tags match this
glob, and b) none of their non-release tags match this glob.

Furthermore, this would mean that the tar_scm source service would
require an extra parameter (which only applies in the git case). It
also would require a patch to tar_scm to add support for your tag
offset mechanism. I believe in freedom of choice, so I would gladly
accept a pull request from you which supports that scheme, in order
that people like yourself can use it.

However, in contrast, the timestamp approach already works out of the
box with tar_scm, and has none of the brittleness described above. So
IMHO it's a better scheme to recommend in the guidelines wiki page.

Regardless, that is not a valid solution,
because it breaks instantly when the first tag is introduced to the
repository.

And why would that be?

Because the tag offset will reset to zero, violating the requirement
that it increases strictly monotonically.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >