Closed matchai closed 5 years ago
What is the purpose of this merge and is there going to be a change to how we should write our commit summaries? Should I read through the Convention Commits specification?
If version incrementing commits are no longer necessary, how would we actually increment the version? Is it done automatically? Under what criteria is it automatically incremented? How about the funny fish themed names?
To add to this, could there please be some guidelines for collaborators such as myself? I'm presuming you'd like to leave the master branch alone and work entirely using merge/pull requests. Are we okay to squash-merge simple pull requests if everything is in order to lessen your load? I'm also guessing you'll always be the only person to increment the version number, since I can't imagine anyone else coming up with such awesome alliterative names. Would you like collaborators to review other's pull requests? Apply appropriate labels? I'd love to be clear and explicit, I don't want to step on your toes! 😊
This merge will make it so that moving forward, spacefish will be automatically versioned. I would suggest you read Conventional Commits spec, as it's not too long.
The version of spacefish should increment on its own, and GitHub releases will automatically be created. With this in place, there should be no issues with having other maintainers merge in requests, as long as they ensure that the squashed commit message fits the Conventional Commits standards.
Unfortunately, this will mean that we will no longer have fun names, unless we manually go back and put them in 😜
In short, based on the commit message prefix, the version will be incremented appropriately:
patch 1.0.0 -> 1.0.1
fix: use only the first battery value for acpi
minor 1.0.0 -> 1.1.0
feat: add rust version section
major 1.0.0 -> 2.0.0
fix: remove poorly performing sections
BREAKING CHANGE: the git, package and node sections have been removed
Fancy as heck! This needs documentation for sure. Could we please have the guidelines updated and expanded upon, with the answers to the above questions as well, in the CONTRIBUTING.md?
Does this mean the funny fish names are over? :sob: :fish:
The reason I was thinking we didn't really need to add it to CONTRIBUTING.md was that it doesn't really need to be enforced by contributors, and only maintainers.
Do you still think it's worth documenting? 🤔
I'll probably still be giving releases names if I've got time to waste. 😛
This isn't really something we can test until we see it run through Travis. 😅 Here goes nothing! 🚀
:tada: This PR is included in version 1.12.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
Description
To reduce the amount of manual effort involved with versioning a release, this PR adds semantic-release to our project. In order to ensure that releases are versioned correctly, maintainers will be using the Conventional Commits spec to standardize commit messages when squashing features branches onto master.
Motivation and Context
Replaces the need to create version-incrementing commits to master.
Types of changes
How Has This Been Tested?
Checklist: