Jan Engelhardt (jengelh@inai.de) wrote:
On Saturday 2014-01-11 14:53, Adam Spiers wrote:
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?
With the match pattern be an argument to whatever script calls that, because that is invariably user-specific, which is also why the match pattern was an argument in the perl script I had posted.
Right, so I understood you correctly.
Hence, all I really asked of the user is to name his tags such and such that he himself can give a reasonable short algorithm to distinguish them.
You're asking that of the *maintainer*, not the packager.
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,
An upstream can always screw up downstream -- heck, they do all the time with something as banal as release tarballs' filenames, which affects our URIs in Source: lines in .spec files, and /debian/watch.
True, but that's out of scope for this discussion about versioning of snapshots directly from an SCM repository.
So, 'lo and behold, git tags are no different.
... which is why I have repeatedly argued that it is not a good idea to rely on them. OTOH, a timestamp is a timestamp, and *can* be relied on, short of the branch being changed or the history rewritten, in which case all bets are off anyway. We don't need to get too concerned about stuff we can't defend against, but we *can* defend against the unreliability of tags.
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.
The offset may move to zero, but in the same go, the tag is increased by "one". Making %version go from 2013.1-1500-gxxxx (2013.1~git1500) to 2013.2-1-gxxxx (2013.2~git1) is perfectly fine.
The tag name is not automatically transplanted into %version. You yourself already described doing that as "almost stupid": http://lists.opensuse.org/opensuse-packaging/2013-09/msg00086.html Therefore this requires the packager to be constantly on the lookout for a tag offset suddenly decreasing, which again is brittle for multiple reasons: - The packager is very often not the upstream maintainer (in fact I'd guess this is true in the majority of cases). - It's not enough to look for a tag offset which drops to zero, because the source service might not run until after several commits since the creation of the new (or first) tag. So it's possible that the offset could drop from (say) 5 to 4, which would be very easy to miss. Worse, if the source service is configured to run automatically server-side, breakage is almost guaranteed after the new tag has been created upstream. It's not at all clear to me why you are so strongly against using timestamping instead, which suffers from none of these problems. Yes, I agree that aesthetically it's maybe not quite as nice, but that's a triviality when compared to the goal of building a robust solution. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org