The version format of your project changes arbitrarily.
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:
- Logical progression of versioning
- Strict compliance is difficult
- Choosing a version scheme is hard
As your product evolves, you will find that your existing version scheme is no longer suitable for your product base and that you must change it. However, you cannot change the versioning scheme of your product without breaking expectations of code compatibility.
As a solution to this problem, I propose Version Versioning as a solution. Developers will initially benefit from saving valuable time having to ensure that their version scheme is constant from one version to the next. You can switch between version schemes at will based on whatever fits your product best at a given moment.
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.
- Each release MUST have a version number.
- A version number MAY be a number.
- A normal version number MAY follow a predefined format, such as SemVer, or it MAY be an arbitrary, developer-defined format, such as YYYY.MM or an incrementing build number.
- Consecutive releases following the same version scheme SHOULD follow the rules defined for that version scheme.
- Non-consecutive releases following the same version scheme MAY follow the rules defined for that version scheme.
- The version scheme MAY change between any two releases.
Write a blog post.
Write a blog post, or include an automatic updater with your product.
Write a blog post.
Write a blog post.
| Company | Product |
|---|---|
| Microsoft | Windows |
| IntelliJ | All IDE products |
| Adobe | Creative Suite products |