Ugh, sorry I will have to complain about SemVer again. I tried SemVer, but later dropped in favor of CalVer. CalVer is used in applications to regular users (take Photoshop and Visual Studio, for example), but I’ve been using with my library, and it works nice.
Am I on the latest version? Do I have to upgrade? Do I have the most recent security patches?
One of the reasons I dropped SemVer is that it let the user with no clue of how old their software (application or library) is. In CalVer this is explicit. It obviously doesn’t tell if the user is using the latest version, but they might recognize that the software they are using is too old.
From these three examples, you can see that semantic versioning is a very concise and structured system for versioning a release. To be fair, there’s a number of further rules in addition to what I’ve covered here. However, these are the basics.
Unfortunately, SemVer doesn’t rule only over the release step, but rule over the development too. If anyone here contribute to third-party OSSs, you might have received an answer like “I’m sorry, but I can’t make this change until next major release”. By then, many changes already happened that your patch already have a lot of conflicts with the current master branch, and even if the conflicts are resolved, your patch might not even work correctly with all the changes that happened in the master branch (example 1 of SemVer ruling over development). I stopped contributing to some OSSs, one of them being a significant OSS, because I had patches waiting for a year.
In CalVer, there’s no rule here. If you find a good way to keep the backward compatibility, good. If you don’t, you still have the choice of merging the patch and informing in the release notes that a break was made.
How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.
I haven’t seen this rule applied with consistency anywhere. Some software stay in <1.0.0 forever. Others have rules like using the x.1.z as beta or alpha.
Have an open release schedule (that changes gradually)
The example used (Ubuntu) is hardly a good example for this. One table contains the past releases, and at the bottom there is the future release. Future release date is good, but shouldn’t be prioritized (example 2 of SemVer ruling over development) over getting the job done, even if it takes a longer time.
Be consistent and predictable… If your release schedule releases a new major release every twelve months, do your best to stick to it.
That’s just SemVer trying to be CalVer. And failing at it, since users will present new bugs and feature requests that will require you changing your schedule.
Communicate changes regularly and transparently
What’s new
What’s been fixed
What’s been improved
What’s been deprecated
Same rules goes to CalVer. Communication is obviously a must. But, it always looks awkward to me when there’s a major release >=2.0.0 for a software, and there’s only a single backward break. While in others there are many.
I remember when Linus was questioning (on G+) if the version of Linux should roll faster. It wasn’t a question of “is what we are currently doing correct and need change?”, it was more like “hey, what about we go faster?” And, I remember he also talked about the interval between the previous major releases and that they had already reached that same interval, indicating that maybe they should also bump the major version (another example of using SemVer as CalVer, but worse).
The version numbers were just numbers. The rules could be broken. And that’s because Linux is a kind of software that can’t be held back by the rules of a version scheme.
Ending my what sounds like a rant.
My CalVer scheme is YYYY.MM.DD.MICRO (could be using only YY for year, too). The MICRO I use for special cases, when I need to make two releases at the same day.
Did the author even read semver.org? It says right at the top that major version is only incremented when incompatible API changes are made. That would imply Firefox has broken its API 57 times already (ok, I do have a problem with it breaking APIs, but it was only like 53 times, not 57).
Seriously though, it’s a hard question. I like the motivation behind semver, and I use it for libraries. The problem with it is that end users are not used to it and often assume that 2.1.0 is a bugfix release for 2.0.0, not a feature release.
It also gets interesting if you have LTS releases, and @ferreiradaselva has a good point. Suppose you have an LTS branch 2.0.x, and you are working on 2.1.x which brings big but backwards compatible changes. Someone (possibly you) writes a useful, safe, well-tested feature that can do no harm to the 2.0.(x+1) release and people want it, but your choice is either to make a 2.1.x release just for that feature and rename the upcoming big release to 2.2.0 to stick with the letter of semver, or break the letter of semver and include a feature in a maintenance release.
I really feel that there is still a lot of questions and practices that still need evolving around the release management and deployment world in general. I didn’t find anybody yet telling me that they feel their deployment workflow is super solid, simple enough for new-commers to plug to, and easy to manage.
I think that there’s still a long road into this area that needs to be done.
Ugh, sorry I will have to complain about SemVer again. I tried SemVer, but later dropped in favor of CalVer. CalVer is used in applications to regular users (take Photoshop and Visual Studio, for example), but I’ve been using with my library, and it works nice.
One of the reasons I dropped SemVer is that it let the user with no clue of how old their software (application or library) is. In CalVer this is explicit. It obviously doesn’t tell if the user is using the latest version, but they might recognize that the software they are using is too old.
Unfortunately, SemVer doesn’t rule only over the release step, but rule over the development too. If anyone here contribute to third-party OSSs, you might have received an answer like “I’m sorry, but I can’t make this change until next major release”. By then, many changes already happened that your patch already have a lot of conflicts with the current master branch, and even if the conflicts are resolved, your patch might not even work correctly with all the changes that happened in the master branch (example 1 of SemVer ruling over development). I stopped contributing to some OSSs, one of them being a significant OSS, because I had patches waiting for a year.
In CalVer, there’s no rule here. If you find a good way to keep the backward compatibility, good. If you don’t, you still have the choice of merging the patch and informing in the release notes that a break was made.
I haven’t seen this rule applied with consistency anywhere. Some software stay in <1.0.0 forever. Others have rules like using the x.1.z as beta or alpha.
The example used (Ubuntu) is hardly a good example for this. One table contains the past releases, and at the bottom there is the future release. Future release date is good, but shouldn’t be prioritized (example 2 of SemVer ruling over development) over getting the job done, even if it takes a longer time.
That’s just SemVer trying to be CalVer. And failing at it, since users will present new bugs and feature requests that will require you changing your schedule.
Same rules goes to CalVer. Communication is obviously a must. But, it always looks awkward to me when there’s a major release >=2.0.0 for a software, and there’s only a single backward break. While in others there are many.
I remember when Linus was questioning (on G+) if the version of Linux should roll faster. It wasn’t a question of “is what we are currently doing correct and need change?”, it was more like “hey, what about we go faster?” And, I remember he also talked about the interval between the previous major releases and that they had already reached that same interval, indicating that maybe they should also bump the major version (another example of using SemVer as CalVer, but worse).
The version numbers were just numbers. The rules could be broken. And that’s because Linux is a kind of software that can’t be held back by the rules of a version scheme.
Ending my what sounds like a rant.
My CalVer scheme is
YYYY.MM.DD.MICRO(could be using onlyYYfor year, too). TheMICROI use for special cases, when I need to make two releases at the same day.Did the author even read semver.org? It says right at the top that major version is only incremented when incompatible API changes are made. That would imply Firefox has broken its API 57 times already (ok, I do have a problem with it breaking APIs, but it was only like 53 times, not 57).
Seriously though, it’s a hard question. I like the motivation behind semver, and I use it for libraries. The problem with it is that end users are not used to it and often assume that 2.1.0 is a bugfix release for 2.0.0, not a feature release.
It also gets interesting if you have LTS releases, and @ferreiradaselva has a good point. Suppose you have an LTS branch 2.0.x, and you are working on 2.1.x which brings big but backwards compatible changes. Someone (possibly you) writes a useful, safe, well-tested feature that can do no harm to the 2.0.(x+1) release and people want it, but your choice is either to make a 2.1.x release just for that feature and rename the upcoming big release to 2.2.0 to stick with the letter of semver, or break the letter of semver and include a feature in a maintenance release.
I really feel that there is still a lot of questions and practices that still need evolving around the release management and deployment world in general. I didn’t find anybody yet telling me that they feel their deployment workflow is super solid, simple enough for new-commers to plug to, and easy to manage. I think that there’s still a long road into this area that needs to be done.