Default label values? - Githubissues

ericclemmons / github-semantic-version

Automated semantic version releases powered by Github Issues.

MIT License

21 stars 8 forks source link

Default label values? #12

Closed ericclemmons closed 7 years ago

ericclemmons commented 7 years ago

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 7 years ago

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 7 years ago

@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 7 years ago

@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.