Lately I’ve come across multiple tweets and talks about people avoiding jumping over the dreaded
1.0.0 of their
frameworks, tools, etc.
If semver defined some simple criteria for what constitutes a 1.x release would that help alleviate the fear?— Colin Eberhardt 🇺🇦 (@ColinEberhardt) August 11, 2015
Why do so many open source projects fear making a 1.x releases? My projects depend on numerous 0.x versions - should that worry me!— Colin Eberhardt 🇺🇦 (@ColinEberhardt) August 11, 2015
Sadly that’s the current state of «our world» as developers.
semver stands for
Semantic Versioning; here’s a excerpt from the website:
Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
As you can see semver specifies a series of numbers (3) to correctly determine the versions of your frameworks.
Notice that its based off
MAJOR should change when you introduce breaking changes (make incompatible changes to the
What I propose! 🎉
Given the fact that most package managers work using semver as their «tagging» base and that most «consumers» of your work will most likely update to whichever version you release as long as is not
MAJOR without having to do much refactoring (e.g. using CocoaPods you can specify something like
~> 1.5 which roughly translates to => «update to every new version above 1.5 as long as its < 2.0.0»)
I propose that everyone maintaining public facing frameworks should support an «intermediate» version right before their
Simply put most modern languages let us mark methods as deprecated; and depending on the language and the compiling flags we can treat this as
warnings ⚠ or
errors ⛔ and the compiler will shout at us when a method is marked as deprecated.
I’m proposing we should release a
PATCH release right before the
MAJOR marking all the methods that will either disappear or change drastically on the next
MAJOR release. This way the consumers will get a warning on their latest automated update and will be prepared what will change on the next
With this they can know what to expect instead of trying to update to the latest
MAJOR and facing a bunch of breaking changes.
To me this seems like a more «friendly» way to alert consumers of what will definitely change/break; also having the compiler warnings there will help some consumers be prepared and start thinking about how to use the new methods BEFORE even having to actually start work to support the latest version of your frameworks.
And that’s it; nothing too fancy or too techie but worth a blog post and maybe let the ball rolling.
Perhaps someone else will share this vision of things and consumers will start getting «warning» releases before every