On Tue, Jun 23, 2015 at 10:48 PM, Pierre-Yves Chibon <pingou@pingoured.fr> wrote:
On Tue, Jun 23, 2015 at 04:46:15PM -0700, Gerald B. Cox wrote:
>    Michael,
>    My belief is that if someone uses the "Release" mechanism, that is covered
>    by
>    the sentence which states: A
>    "If the upstreamA doesA create tarballs you should use themA as tarballs
>    provide an easier trail for people auditing the packages."
>    By creating the tag, upstream has clearly indicated their intent; A who
>    are we to second-guess them? A

I disagree on this as tags are not something that is definitive.
There is a way in github to upload a given tarball and that is then definitive
but just pushing a tag isn't.
There are really too many upstream moving a tag around.

The whole point of the guidelines is to address this specific problem: tags in
github are not definitive, which means they cannot be approach like a version on
pypi or cpan or other platform.


>    The commit hash part comes into play when a Revision or Tag has not been
>    created.

Well, if there is not release, there is no other way than using the hash, but
tags are not releases and thus should not be consider as such.

I agree that tags have potential problems, but it seems that a lot of projects are not doing releases and are only using tags. I think that coming up with a standard policy of how to handle that would be a really good thing. I'm not familiar with all of the download options from github, but if there's a way to make the hash of the commit be part of the URL, then that should help address the issue with tags changing.