ericclemmons/github-semantic-version

Default label values?

ericclemmons opened this issue · 3 comments

ericclemmons commented

Currently, the recommended labels are:

https://github.com/ericclemmons/github-semantic-version#packagejson-example

  • Is this something that's required?
  • Should it be optional?
  • ...and should we throw if a repo has none of these labels?
comamitc commented

I think the question (if not required) would become, what is gsvs default behavior if the declarative versioning strategy is missing from GH (or some other system's) config.

Personally, I think it'd be cool to support [patch|minor|major] in merge commit messages and/or patch|minor|major/branch-name prefixes in the branch name. That's outside of the scope of this question though!

daveashworth commented

@ericclemmons Currently it bails if there aren't any user defined labels.

My thinking behind this was I wanted the user to be fully aware of the labels they need to create on their repo in order to for them to affect the version calculation (vs defaulting to certain labels and the user wondering why the version calculation isn't matching what they expected).

ericclemmons commented

@comamitc I'd be cool with using the default bug & enhancement labels for patch & minor releases, respectively.

I agree with @daveashworth that there should be a cognitive, required step.

  • Having Github labels is a hard requirement. (Errors are thrown otherwise)
  • Listing those in the package.json is currently a requirement, but I can see us relaxing that in the future once we're copy/pasta'ing.

Going to close to revisit after we apply this project in multiple places. What I was trying to convey to Kent C. Dodds is that, AFAIK, github issues/prs are the best, mutable place to upgrade an existing project with semantic versioning/changelog/release.