Versioning

Semantic Versioning

SWING will use the conventions for semantic versioning outlined in https://semver.org/.

The basic rules include:

Z specifies the patch version. It is incremented when backwards compatible bug fixes are made. Reset to 0 when X or Y are incremented.
Y specifies the minor release. It is incremented when backwards compatible API changes and features are made. It can include patch changes. Reset to 0 when X is incremented.
X specifies the major release. A major release is necessary when backwards incompatible API changes are made. It may include minor and patch changes.
SWING will be in pre-release until. While in pre-release, the API should be considered unstable, and can change quickly. This will be noted on GitHub and the GitHub Pages. Version 1.0.0 will be released when a stable, production ready API is available.
Changes should be made on a development branch and merged to master. NEVER make changes directly to master
Each new version should be tagged and include a description of the updates.

Here are examples of how versioning should work:

(Increment Z) A bug fix is necessary to a function because a value was accidentally hardcoded. The version should be updated from v1.2.3 to v1.2.4
(Increment Y) A new function needs to be added. Additional bug fixes also are made. The version should be updated from v1.2.3 to v1.3.0
(Increment X) An existing class is deprecated, but new classes and functions are added to expand SWING capabilities. The version should be update from v1.2.3 to v2.0.0