Skip to content

Instantly share code, notes, and snippets.

@balupton

balupton/README.md

Last active August 29, 2015 13:56
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save balupton/9087506 to your computer and use it in GitHub Desktop.
Save balupton/9087506 to your computer and use it in GitHub Desktop.
Download ZIP
Semantic Versioning Issues
Raw
README.md

Semantic Versioning is great. It adds semantic meaning to those pesky version numbers.

The most popular semantic versioning standard is semver, which states:

revision = for b/c bug fixes with no public api changes/additions
minor = for b/c public api changes/additions
major = for b/c breaks around new public api changes/additions
accept revision and minor for changes (^ character)

However, unfortunately, this is flawed:

  1. The definition of minor and major are flawed as:

    1. There are things outside the scope of the public API that could break a program.

      1. E.g. With a pre-processor, the public API could stay intact, but changes in the parsing of source content, or changes in the output of the pre-processed content, could break things within your application.

    2. Fixing a b/c break that is due-to/coupled-with new changes/additions, makes fixing the problem impossible, as the fix would be now be b/c break in itself, as now people depend on the code that broke your stuff, so fixing it would break there stuff.

      1. E.g. Backbone.js releases v1.1.0 which changes the return values of some of the functions, which breaks some people's code. Releasing a v1.2.0 that reverts the change (and a v2.0.0 with the change) will now break all the programs that dependended on the v1.1.0 way of doing things.

    3. Any changes/additions, anything that isn't merely a bugfix, risks introducing new problems.

      1. We can't know whether or not we have always broken b/c, but we can estimate a likelihood for this. However the definition here doesn't care about likelihoods or risks, it only cares about ideal intentions.

  2. The recomendation of automatically accepting minor releases is flawed as:

    1. The only thing we should care about is accepting backwards compatible bug fixes, not new or different functionality.

      1. We don't, nor why should we ever care about accepting versions automatically into our 6 month old program that introduces public API additions/changes that we don't even use or care about, at the risk of it breaking things for no benefit to us.

Because of this, instead a better standard of semantic versioning is:

revision = no b/c breaks for anyone (for b/c bug-fixes/improvements)
minor = possible b/c breaks for some (for api changes/additions and b/c breaking bug-fixes/improvements)
major = b/c breaks for all (for api changes/additions and b/c breaking bug-fixes/improvements)
accept revision for changes (~ character)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment