Semantic Versioning is very popular of course. It basically takes the form of:
major.minor.patch-prerelease+build
- Major for breaking changes.
- Minor for backwards compatible feature additions.
- Patch for bugfixes meant to be backwards compatible.
- Pre-release tags for internal versioning, building up to a release.
- Build for internal build numbers, useful if you build a lot.
Pre-release and Build tags do not participate in the precedence order. So when specifying ranges of versions, those pre-release tags are kind of ignored in things like NPM contrary to precedence order as SemVer defines it --- reality is different than theory, right?
Pre-release tags are great for Designating development stages but when they are removed to do a non-pre-release release (e.g. a final release), it messes up the lexicographical ordering --- i.e. messes up the order in which they show up in my file browser. haha.
How I use SemVer
So I'm trying a SemVer compatible system that respects the 2nd and 3rd laws: "Don’t mess with math", and "Make friends with infinity. In other words, don’t be afraid to increment".The basic idea is: keep pre-releases to a patch level, release at the next patch level.
The rules are:
- Start at 0.1.0.
- Increment patch number to make a release
- Increment major, minor, or patch (whichever you're targeting for next) to make pre-releases
- Pre-releases are tagged a1, a2, ..., b1, b2, ..., rc1, rc2, etc.
- Use increasing build numbers if you need
- Use a "." then another build field if you must, like for adding a non-increasing alphanumeric build field (e.g. a SHA)
Example
So you'll get versions of WildApp like these, e.g.:- WildApp 0.1.0-a1
- WildApp 0.1.0-a2
- WildApp 0.1.0-b1
- WildApp 0.1.0-b2
- WildApp 0.1.0-b3
- WildApp 0.1.0-rc1
- WildApp 0.1.0-rc2
- WildApp 0.1.1
- WildApp 1.0.0-a1
- WildApp 1.0.0-a2
- WildApp 1.0.0-b1
- WildApp 1.0.0-b2
- WildApp 1.0.0-b3
- WildApp 1.0.0-rc1
- WildApp 1.0.0-rc2
- WildApp 1.0.1
No comments:
Post a Comment