I’ve decided to use my own version number scheme for QubeKwest. It’s not that I find other schemes to be bad, I just wanted to come up with my own. My goal here is simplicity for version checking, logic for talking about versions, and in general just easy to follow. What follows is the scheme I’ve adopted.
- Version Numbers are always integers and increase sequentially for actual releases (patches, major changes, minor changes, all increase the version number the same way).
- There are no fractional parts to any version numbers.
- There are no letters to any version numbers.
- Development versions are negative numbers that match the positive production version they will become.
- There is no version 0.
- Version data is a 32-bit signed integer value allowing roughly 2 billion versions and 2 billion development versions.
- Versions are not designed to be especially “human friendly” so if several patches are released in short order, they will all just be separate versions.
- Breaking changes will include automatic upgrade logic to repair data created by old versions.
- Client and Server parts will always be matched version numbers.
- Servers will respond with a version mismatch failure for any Client of a different version attempting to connect.
Examples
- Version 3 comes after Version 2 (regardless of how big a change it was).
- A public development release of Version -6 (negative six) will eventually become a production release of Version 6.
- A Server of Version 4 will only talk to a Client of Version 4.
- Version 11 will include automatic upgrade logic for correcting data structures from any lesser version up through Version 11.