-
Notifications
You must be signed in to change notification settings - Fork 3
Versioning of roles #168
Comments
Yeesh, that reads like an IETF RFC... is there a good comparison/contrast between PEP-440 and Semantic Versioning? It seems like at least the core components of semver would be acceptable (e.g. Edit: I did see a Semantic Versioning section. Looks like the core part is fine, but tags like |
Notable: this is the mechanism for PyPi versioning, and this spec was written by the author of PyPi. |
@gregdek - I know you closed #165 in favor of this issue, but would this issue technically cover some sort of locking mechanism as well? E.g. If I wanted the latest of a "3.1.x" branch (and could choose 'stable', 'dev', 'alpha' etc.), is that the desired outcome of this issue? Or is it more just agreeing to or documenting the use of PEP 440? If the latter, could we leave the Lockfile/version pinning issue open? |
We can reopen if you like, sure. I suppose they are separate issues. |
I'd vote for limited semvers as defined in pep-440 but I have simple needs and don't know most edge cases. |
We already allow 'commit sha' as a 'role version' |
This issue was moved to ansible/galaxy#83 |
Time to start figuring this out. Unless there's significant backlash, because we live in the Python world here at Ansible, we're likely to implement PEP-440 for versioning:
https://www.python.org/dev/peps/pep-0440/
The text was updated successfully, but these errors were encountered: