Clarify when we issue major vs. minor vs. patch releases

[josh-padnick]

The community recently gave us helpful feedback that we issued a patch release that included what some users saw as a breaking change.

This prompted some internal discussions at Gruntwork about the root cause of the confusion. We believe the core issue here is that we haven't published clear guidelines on what constitutes a major vs. minor vs. patch release, and that even internally we weren't crystal clear on these nuances.

As a result, I'm proposing in this GitHub issue that we:

1. Add clear public docs on what constitutes a major vs. minor vs. patch release
2. Reach a conclusion internally on when issuing a 1.0 release makes sense

We'd welcome additional feedback on any guidelines you'd like to see in our release process!

[ruijarimba]

Add clear public docs on what constitutes a major vs. minor vs. patch release

Maybe just follow Semantic versioning?

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes
• MINOR version when you add functionality in a backward compatible manner
• PATCH version when you make backward compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.