-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version string in release archives changes, which makes packaging harder #151
Comments
Hashes changed, see isamert/scli#151
Hashes changed, see isamert/scli#151 (cherry picked from commit a22bf33)
Thanks for reporting, and for pointing to the same problem in the python-versioneer repo! I can see how this is an issue for the packagers. We definitely want to make life easier for you guys! Here is what's happening:We want Now, the problem arises because the archive files that GitHub provides for downloading, like the 'source code' files on the releases page, are generated dynamically at download time. This implies that there is no guarantee that the hashes of zip / tar.gz files downloaded at different times will stay the same. It's the same thing that causes #143. Potential solutions
I am leaning towards the first option as the "least worst". It will also solve #143 and the potential future issues arising from relying on dynamically generated archive files. But none of the above seem ideal. Suggestions welcome! @0mp has this come up in the past? Is this commit relevant? (The message "Fix scli --version") @alexeyre can this be a problem for nixpkgs too? |
@exquo What about using the %(describe) placeholder instead? It's available since git 2.32. Example:
The above matches all annotated tags which start with a "v". So the one caveat is that tagging has to happen using The results look like this:
Which relate to:
I created a test repo to verify that this is actually supported by github: grembo/gitformattest Testing shows that version strings stay stable this way. |
The next release of git should contain this change, which will allow to do:
to get rid of the annotation requirement on tags (even though, I kind of like using them anyway). |
That's exactly what we need here, thanks so much! I'm on an older git version, so was not aware of this addition. Ironically, it's right there next to
Yes, we're using git's annotated tags. I agree it's a good practice regardless. If you want to make a PR with this change to the That should take care of this particular problem, but other issues caused by changing hashes of dynamically generated files might come up in the future. So, (note-to-self), we might still want to start uploading our own archive files to the releases. |
This should make auto-generated tarballs more stable, which helps packagers. Addresses isamert#151
This should make auto-generated tarballs more stable, which helps packagers. Addresses isamert#151
This should make auto-generated tarballs more stable, which helps packagers. Addresses isamert#151
(tagging @0mp, who is maintaining the FreeBSD port)
VERSION contains a version string that changes based on the state of the archive.
scli/VERSION
Line 1 in d9b38cf
This means, right after v0.6.5 was released, the file contained:
d2f437a (HEAD -> master, tag: v0.6.5, develop)
later this changed to
d2f437a (tag: v0.6.5).
This results in hashes of artifacts changing, which means package builders relying on those being correct end up not being able to fetch the package - one would think that official artifacts stay the same, but it appears that this might actually not be the case (comparing contents of v0.6.6 and v0.6.5 sources on the release page lead to this assumption).
There a discussion about this here: python-versioneer/python-versioneer#217
The text was updated successfully, but these errors were encountered: