-
Notifications
You must be signed in to change notification settings - Fork 47
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
Unable to resolve version from lightweight tags #14
Comments
It's a design decision to only consider annotated tags (aka exclude lightweight tags). I should document that. But what do you mean by "created by GitHub when cutting a new release"? Aren't GitHub releases based on the user published tags? |
Not necessarily. It is possible to create a new release from Releases GitHub page which will in turn create a new tag. That tag is going to be a lightweight one. |
Is there a problem when considering lightweight tags in the describe? |
Using lightweight tags to define the version means you can never use tags for anything but the version. For instance you can't create a local "before-refactor" tag, for your convenience, and you have to use SHAs all the time. I personally believe this is a waste of a great feature in git, so I prefer only annotated tags are used for versions. But I'm happy for sbt-dynver to have an opt-in feature that includes lightweight tags. |
Are you concerned of a version being inadvertently derived from a tag which was not meant to be a version tag?
Or is there something else that I am missing? |
You're right, I forgot about that safe-guard - I agree it makes the risk very low. Go ahead, and welcome, my first contributor :) |
Fixed by #15 |
which are the tags that are created by GitHub when cutting a new release.
Can be fixed by adding
--tags
to thegit describe
command. PR incoming.The text was updated successfully, but these errors were encountered: