The version of your product is and always will be 10.
As you manage a software product, you will have many choices on how to manage the versions of it. Most versioning systems have the following problems:
- Increasing complexity over time
- Dependent on manual human intervention
- Non-deterministic rules
As your product evolves, you will bottleneck on human-to-human communication and waste time with "version bump" code changes just for the sake of versioning your code. Additionally, we can't get rid of versioning or lock it as it provides a valuable tool for people to understand the compatibility of your code.
As a solution to this problem, I propose Ten Versioning to solve these problems. Developers will initially benefit from saving valuable time to automation of version numbers. As the product evolves, it will be easier for people to contribute due to the removal of conversation for version increments. While popular systems like Semantic Versioning can create complex versions like "1.0.0-alpha+001, 1.0.0+20130313144700", Ten Versioning will convey the same information for the same code with a double-digit integer.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
- A normal version number MUST take the form 10.
- Version 10 MUST be backward compatible with versions before 10.
- Version 10 MUST be future compatible with versions after 10.
You already have.
Simply pin to version 10. This will never be a problem if TenVer is adhered to.
Use a different code repository.
| Company | Product |
|---|---|
| Microsoft | Windows 10 |
| Apple | OSX |
| Google X team projects |