Repository navigation
Versioning Software
Semantic Versioning:
- MAJOR means API version
- MINOR means this development cycle (might change often if cycles are short)
- PATCH means the users don't need to care about this release
Define your release cycles. You are allowed to ship new features at the end of each cycle. The length does not have to be consistent, just agree with your teammates.
- Development snapshots may have versions like
1.2.git328a3b. You probably don't give this to your users. - If you want to ship release candidates, those have versions like
1.2.rc1. - The artifact you release at the end of the release cycle has version
1.2. - Then if you fix a bug in that, you will push a version
1.2.1.
Bump version in the source code after releasing. When 1.2 is released, replace the version in the source code to 1.3 immediately.
Applications don't really have versions in this case, you are only interested in the most recent version. Use the pipeline build number as the version.
Libraries do have a major version. You can add new APIs without increasing this, but you cannot remove old APIs. Version your namespaces (major only). Minor and patch numbers are meaningless, use the pipeline build number instead. Create stable APIs. Branch by Abstraction for breaking changes.
Each commit is a release. Each commit may add new public APIs or change unstable APIs. But only major releases are allowed to remove (change) stable APIs.
The source code only has the major version.
If the product is for end-users (like an app or a service), don't bother with versioning, use the commit hash. Version your API namespaces.
If the product is a library, still don't version the whole repo, but define a major version for the library API. The same source can provide v1 and v2 of the same API.
Branch by Abstraction for breaking changes.
Resources: