Awesome Versioning

Software versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software. (Wikipedia)

Welcome to our curated list of all things awesome related to the practice of versioning software!

Contents

• Tools
• Versioning Schemes
  • General Schemes
  • Restricted Schemes

---

Tools

Helpful programs to ease the hard task of assigning versions.

• Semantic Version Util (svu) - Print the current version, increase patch/minor/major manually or just get the next tag based on your git log.

• BumpVer - Search for and update version strings in your project files.

Versioning Schemes

Unique ways to uniquely version the unique states of unique projects!

General Schemes

The author(s) or maintainer(s) of the following schemes MAY intend them for use by projects of all maturity levels.

• Semantic Versioning (SemVer) - Version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.

• Break Versioning (BreakVer) - Emphasizes the maximum amount of damage a version update could inflict.

• Calendar Versioning (CalVer) - A versioning convention based on your project's release calendar, instead of arbitrary numbers.

• 0-based Versioning (ZeroVer) - Your software's major version should never exceed the first and most important number in computing- zero.

• Romantic Versioning (RomVer) - An attempt to extract 'versioning spec' from real-world usage of software versions (like in Node, Rails, PHP, jQuery, NPM, Linux Kernel).

• Chronologic Versioning (ChronVer) - Communicate changes to your project with specific temporal-based increments to the version number.

• Hash Versioning (HashVer) and GitDate - Suited for constant small releases

• StableVer - It should always be possible to migrate from major version N to major version N+1 without breaking changes -- provided that you are not using any features that were marked deprecated in version N.

• Pragmatic Versioning - Communicates changes to a package to package consumers, while retaining simple semantics for package maintainers.

• Intended Effort Versioning (EffVer) - Version your code by the effort required to upgrade.

• SoloVer - Intentionally do not try to communicate "backward compatibility" as there is no objective and satisfying definition anyways.

Restricted Schemes

Programmers are warned that the author(s) or maintainer(s) of the following schemes MAY NOT intend them for general use.

• πVer and eVer

  The current version number for is 3.1, and for METAFONT it is 2.7. If corrections are necessary, the next versions of TeX will be 3.14, then 3.141, then 3.1415, …, converging to the ratio of a circle's circumference to its diameter; for METAFONT the sequence will be 2.71, 2.718, …, converging to the base of natural logarithms. I intend to be fully responsible for all changes to these systems for the rest of my life. I will periodically study reports of apparent bugs, and I will decide whether changes need to be made. Rewards will be paid to the first finders of any true bugs, at my discretion, but I can no longer afford to double the size of the reward each year. Whenever I have created a new version, I will put it in the official master TeX archive, which currently resides at Stanford University. At the time of my death, it is my intention that the then-current versions of TeX and METAFONT be forever left unchanged, except that the final version numbers to be reported in the "banner" lines of the programs should become TeX, Version $\pi$ and METAFONT, Version $e$ respectively. From that moment on, all "bugs" will be permanent "features."

• Haskell Package Versioning Policy (PVP) - An attempt to formalize the informal policy in use in the Haskell community.

• WendtVer - Version numbers and the way they change convey utter chaos and no meaning about the underlying code, but are easy to figure out what the next version will be.