Learn what semantic versions are and how Codebots uses them.
This article is based on the information available at https://semver.org/
Semantic versioning refers to a set of rules that dictate how version numbers are assigned and incremented. Under this scheme, version numbers and the way they change are used to convey meaning about the underlying code and what was modified from one version to the next.
Codebots enforces the use of semantic versioning in the Launch section.
A version number is composed of 3 major numbers, each having a separate meaning. Together, they create the format
MAJOR.MINOR.PATCH, each of which are incremented in different scenarios:
- MAJOR increments when you make incompatible or (potentially) breaking changes,
- MINOR increments when you add functionality which is backwards compatible (or doesn’t affect any other pieces of functionality), and
- PATCH increments when you make backwards compatible bug fixes or small changes which don’t affect existing functionality.
- Your first version might be
- You add in a new piece of functionality that never existed before. Since no existing functionality would break (and is therefor backwards compatible), it would only be considered a MINOR change. Therefore, your version number would increase to
- You alter that new piece of functionality in a way that is no longer compatible. Since existing functionality would break, it would be considered a MAJOR change. Your version number would increase to
- You make a small fix to change a typo. It does not have have any effect on existing functionality, and therefore would be considered a PATCH change. Your version number would increase to
Read more FAQs at https://semver.org/#faq
Q: What happens to the MINOR and PATCH numbers when I increment MAJOR?
A: Like decimals, the lower denominations are ‘reset’ back to 0 (e.g.
3.2.1 would be incremented to
4.0.0, and not
4.2.1). The same rules applies to a patch number when the minor version updates.
Q: How do I know when to release
A: Generally when you application first goes to production, it is considered version
Q: If even the tiniest backwards incompatible changes require a MAJOR version bump, won’t I end up at version
42.0.0 very rapidly?
A: This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you’ll think through the impact of your changes, and evaluate the cost/benefit ratio involved.