Semantic Versioning

[devlinjunker]

Enforce semantic versioning so we can easily identify which build we are working on and create releases

https://hodgkins.io/automating-semantic-versioning
https://github.com/intuit/auto
https://github.com/semantic-release/semantic-release/tree/master/docs/usage

• Githooks to enforce commit message conventions for semantic-release:
  https://www.conventionalcommits.org/en/v1.0.0/
• template commit message with comment explaining the different commit message components
• action to:
  • increment version
    • based on commit messages
    • based on labels?
  • cut release branch
  • create tag
• Add version to top of README (see Add Version Information to README file #16)

---
version: 0.8-SNAPSHOT
---

• [ ] look into Cleanup readmes and docs/wiki #18 first?
• force squash merge only (see Consider Squash or Rebase only? #17) and expect good commit message
  • how do we enforce message?
    • chrome extension to prevent bad messages?
    • action to verify commit message and remove commit if invalid (from both branches?) PR will need to be-opened...
    • other ways to ensure commits to master follow commit message conventions?
    • https://github.community/t/how-to-change-the-default-squash-merge-commit-message/1155/20
  • bulldozer will be used on develop branch to squash and merge
  • main will only allow merge commits

[devlinjunker]

see devlinjunker/template.hapi.rest#13 for more notes and ideas

[devlinjunker]

https://github.com/sdras/awesome-actions#semantic-versioning

[devlinjunker]

Manually started creating releases and versioning: https://github.com/devlinjunker/template.github/releases/tag/v0.8.0

[devlinjunker]

• Add badge with GitHub version/release/tag
  https://shields.io/category/version

[devlinjunker]

Read current version out of README:
cat ../../README.md | sed -n "/version: [0-9]*\.[0-9]*\.[0-9]*/p" | sed "s/version: //"

or will we be using git tags to determine previous/next version?