-
Notifications
You must be signed in to change notification settings - Fork 3
Use semver for role versions #70
Comments
👍 |
👍 essential feature. |
Come on, guys. Three thumbs-up from the same org is no more informative than one thumbs-up. :) It's something to consider, but we want to be careful; not everyone uses semver, and not everyone is familiar with the particular packaging notations for npm. We don't want to require use of semver, or even assume it to be the default. Are you talking about a full implementation of semver here? |
Ooops, so much love in our organization, that everyone is looking in the same direction :) Anyway, semver is not essentially related to npm, it slowly become a defacto standard for such things. We naively thoughts that ansible galaxy already implements it, and starts to plan our role git workflow in this manner (see https://github.com/ElaoInfra). And yes, we were talking about a full implemenatation. We realize that it could be a backward incompatible point for people using ^ or * or ~ in their tag/branch names.... |
Understood. Can't promise it soon, but now it's definitely on the list. Thanks! |
👍 essential feature |
👍 any news on this issue? |
I would also vote for this feature. https://pypi.python.org/pypi/semantic_version/ might help implementing this (it's not said in the documentation but it also supports caret ^ and tilde ~ notation for pessimistic comparison). Using git as scm and having the repository url, existing tags could be retrieved using "git ls-remote --tags " and be matched against a spec using the python package above. Unfortunately my programming skills are not smart enough to contribute on my own. |
+1 Server and lock file would be wonderful, please. |
+1 |
Using "version" parameter in a yaml role file like this:
makes ansible-galaxy trying to download a strictly version-linked archive on github like this:
So, "1.0" could only be either a branch or a tag.
I would be a nice thing to use semver in such a situation, like this:
So that we can respect the traditional git workflow, meaning that master is the main current branch, and patch (in a semver point of view) are just tags on master.
The text was updated successfully, but these errors were encountered: