Add missing git tag for 0.11.3 release #167
Comments
…rpose routines securesystemslib supports public-key and general-purpose cryptography, such as ECDSA, Ed25519, RSA, SHA256, SHA512, etc. Most of the cryptographic operations are performed by the cryptography and PyNaCl libraries, but verification of Ed25519 signatures can be done in pure Python. WWW: https://github.com/secure-systems-lab/securesystemslib [1] secure-systems-lab/securesystemslib#166 [2] secure-systems-lab/securesystemslib#167 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@501637 35697150-7ecd-e111-bb59-0022644237b5
…rpose routines securesystemslib supports public-key and general-purpose cryptography, such as ECDSA, Ed25519, RSA, SHA256, SHA512, etc. Most of the cryptographic operations are performed by the cryptography and PyNaCl libraries, but verification of Ed25519 signatures can be done in pure Python. WWW: https://github.com/secure-systems-lab/securesystemslib [1] secure-systems-lab/securesystemslib#166 [2] secure-systems-lab/securesystemslib#167
…rpose routines securesystemslib supports public-key and general-purpose cryptography, such as ECDSA, Ed25519, RSA, SHA256, SHA512, etc. Most of the cryptographic operations are performed by the cryptography and PyNaCl libraries, but verification of Ed25519 signatures can be done in pure Python. WWW: https://github.com/secure-systems-lab/securesystemslib [1] secure-systems-lab/securesystemslib#166 [2] secure-systems-lab/securesystemslib#167 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@501637 35697150-7ecd-e111-bb59-0022644237b5
…rpose routines securesystemslib supports public-key and general-purpose cryptography, such as ECDSA, Ed25519, RSA, SHA256, SHA512, etc. Most of the cryptographic operations are performed by the cryptography and PyNaCl libraries, but verification of Ed25519 signatures can be done in pure Python. WWW: https://github.com/secure-systems-lab/securesystemslib [1] secure-systems-lab/securesystemslib#166 [2] secure-systems-lab/securesystemslib#167 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@501637 35697150-7ecd-e111-bb59-0022644237b5
|
@koobs, the 0.11.3-release was git-tagged as @awwad, do you know why we switched to prefixing |
|
@lukpueh It's an issue with regard to automatic update detectors that downstreams use (incl FreeBSD) that look for either (or both) pure-version tags or name-version tags upstream to detect new versions. The most standard convention that's easiest to predict/parse is: X.Y.X (no prefix/suffix) |
|
Okay, noted for upcoming releases, @koobs. Is there anything you need us to do for past releases? Out of curiosity, do you (others?) not scan for |
|
Anything consistent is fine, as we can codify that prefix into the 'distribution version'. That aside I prefer prefix/suffix-less (and I see more python package upstreams dropping 'v' lately), but I won't die on that hill :) |
|
As far as past/future releases go, other than #166 it looks OK |
|
I made a mental note to go back to vX.Y.Z in future releases. And I also opened a ticket to make this a guideline (see secure-systems-lab/lab-guidelines#20). Thanks again for your valuable input, @koobs! Closing here... |
Using the GitHub sources to grab packages tests until they ship in the PyPI sdist (See #166), I noticed the git tag for the latest 0.11.3 release is missing.
This is a request to add that git tag for the commit hash which corresponds to the currently released 0.11.3 tarball on PyPI.
Our FreeBSD ports (by default), use the canonical version (0.11.3) as an argument to pass to GitHub's API to fetch a specific version of the sources. In the absence of a matching git tag, we need to use a commit hash, which can be unreliable (not exactly the specific version uploaded to PyPI)
Thanks!
The text was updated successfully, but these errors were encountered: