Why we’re switching to calendar versioning(cockroachlabs.com)
cockroachlabs.com
Why we’re switching to calendar versioning
https://www.cockroachlabs.com/blog/calendar-versioning/
166 comments
> The whole point of semver is that it allows people to know if they can upgrade version without hitting incompatibilities. So yes, this would be a 2.2 and those on 2.1 would know that they could upgrade to it without worrying about fixing their own integrations.
No. Semver states quite clearly that "Major version MUST be incremented if any backwards incompatible changes are introduced to the public API.".
It does NOT state that the Major verson MUST NOT be incremented if the api has no backwards incompatible changes.
You can increment the MAJOR component of the version number at your will. So this is quit clearly a 3.0.0 release. Or it could be a 40.0.0 release and it would still be valid semver.
No. Semver states quite clearly that "Major version MUST be incremented if any backwards incompatible changes are introduced to the public API.".
It does NOT state that the Major verson MUST NOT be incremented if the api has no backwards incompatible changes.
You can increment the MAJOR component of the version number at your will. So this is quit clearly a 3.0.0 release. Or it could be a 40.0.0 release and it would still be valid semver.
IMO it’s kind of implied by semver that a major version increment means breaking changes. If you increment major version without breaking changes then you aren’t really doing semver IMO.
It’s like if you have a fire alarm that goes off when there’s a fire but which also goes off randomly all of the time. People are going to stop listening to it, because even though it reliably rings when there’s a fire the fact that it rings is unlikely to mean there’s an actual fire.
In the same way, if you keep incrementing the major version without breaking changes then people can no longer rely on the version number to be alerted about breaking changes.
By all means, increment your major version number when you feel like it. Just don’t call it semver. Because even if you are technically allowed to, it goes against the spirit / point of semver IMO.
It’s like if you have a fire alarm that goes off when there’s a fire but which also goes off randomly all of the time. People are going to stop listening to it, because even though it reliably rings when there’s a fire the fact that it rings is unlikely to mean there’s an actual fire.
In the same way, if you keep incrementing the major version without breaking changes then people can no longer rely on the version number to be alerted about breaking changes.
By all means, increment your major version number when you feel like it. Just don’t call it semver. Because even if you are technically allowed to, it goes against the spirit / point of semver IMO.
Just add an unnecessary breaking change and everything's perfect.
This is the correct answer! IMHO.
A perfect solution that strikes the balance between an engineer's unrelenting desire for correctness and the marketing departments seemingly irrational need for perceived progress.
A perfect solution that strikes the balance between an engineer's unrelenting desire for correctness and the marketing departments seemingly irrational need for perceived progress.
I think the key part of your answer is "IMO". Incrementing the major without breaking is still semver, where wether you think so or not. One example for you is a package that was javascript and moved to typescript. Same everything, but they increment the major.
Sometimes, it makes sense to increment MAJOR for a significant change, like a complete rework of the code, even if it's purely internal and doesn't break the API. In such cases, even if nothing is supposed to change "on paper", it will probably have an impact (different performance, lower stability for the few first MINORs/PATCHs, etc).
But incrementing MAJOR on a yearly basis, if the major only changes by year, doing dep=X.* in your requirements.txt/package.json/Gemfile doesn't make much sense, if one of my dependencies has not significantly changed, why should I increase a version number in my dependency manager? It's just unnecessary work.
It can also raise interesting existential question if you have to release a version with a breaking change (let say, a security fix that necessitate a change in the API). What do you do then? If you don't increase MAJOR, you don't follow semver, if you increase it, you break your versioning pattern, and release 20.0 in 2019.
But incrementing MAJOR on a yearly basis, if the major only changes by year, doing dep=X.* in your requirements.txt/package.json/Gemfile doesn't make much sense, if one of my dependencies has not significantly changed, why should I increase a version number in my dependency manager? It's just unnecessary work.
It can also raise interesting existential question if you have to release a version with a breaking change (let say, a security fix that necessitate a change in the API). What do you do then? If you don't increase MAJOR, you don't follow semver, if you increase it, you break your versioning pattern, and release 20.0 in 2019.
I agree, people shouldn't be afraid of v3.27.0
By that interpretation, their calendar versioning (19.1.0) is also valid semver, because there's no rule about NOT just incrementing whatever whenever.
Except that for it to remain both valid calver and valid semver, they would have to delay all breaking changes until January every time they come up.
They seem to indicate that they aren't expecting any more breaking changes, but yes, that's generally true.
It's not valid if 19.2 introduces breaking changes form 19.1
true, but doing that makes no sense, because people who made their software depend on major v18 are not switching automatically, because they first need to check if any breaking changes happened and if they need to modify their own software. Semver is "semantic" for a reason - to simplify this daunting task. Increasing major version even when there are no breaking changes is technically still semver, but without the helpful warranty, so it completely misses the point
The problem of semver is that everyone interprets the compatibility differently. There are some language-supported criteria, but that does not cover all important use cases. In addition, any reasonable compatibility criteria might be impossible for large enough softwares---every revision can be potentially major in the semver terminology and it won't deliver much value to the user anyway. The calender versioning is useful for such cases.
I read that as "the problem with semver is it's not perfect". Well yeah. But no semver is worse: upgrading is hard enough when devs communicate on what breaks, but when they don't, it's just a nightmare.
Semver get 80% of the job done. The 20% will still suck but Pareto and I agree that it's a pretty good deal given the effort.
Semver get 80% of the job done. The 20% will still suck but Pareto and I agree that it's a pretty good deal given the effort.
You should be reading it as "the problem with semver is that it does not solve the problem it purports to solve."
An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business." From a risk-management perspective, at least calendared versioning implies that you'll have to do your own homework on which upgrades are incompatible, which is at least more honest than ineffective rigor.
An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business." From a risk-management perspective, at least calendared versioning implies that you'll have to do your own homework on which upgrades are incompatible, which is at least more honest than ineffective rigor.
Are you saying that knowing that there is an 80% starting chance of it not breaking anything is not any better not knowing that? That knowing that the devs don't think anything will break or not is worthless? And that is not counting the times when they do bump the major version to tell you it will probably break something.
The 100% solution you imply as a strawman here doesn't exist and some information is better than no information. And no one said Semver means you don't test, it just guides you on the expected behavior of the new release.
The 100% solution you imply as a strawman here doesn't exist and some information is better than no information. And no one said Semver means you don't test, it just guides you on the expected behavior of the new release.
> An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business."
Maybe if you deploy directly to production before any testing is done.
Maybe if you deploy directly to production before any testing is done.
An 80% solution means you have 80% fewer unexpected breakages.
I think the language-backed semver can be useful (I really want Cargo to support this mode!). The general unguided semver seems less useful.
I envision a much simplified alternative (or analogue) to the semver: there is a single decimal revision, and you should strive to be compatible back to the first revision. When you are willing to break the compatibility, you simply rename. This is similar to Go's practice but can be technically made compatible to the three-part semver (by encoding minor and patch versions to the decimal).
I envision a much simplified alternative (or analogue) to the semver: there is a single decimal revision, and you should strive to be compatible back to the first revision. When you are willing to break the compatibility, you simply rename. This is similar to Go's practice but can be technically made compatible to the three-part semver (by encoding minor and patch versions to the decimal).
This is my issue with semver. I don't care about minor non breaking change, just give me the latest.
Breaking change is the only thing I want to know about so realistically I only need to worry about major version updates right?
So lib: 1.* Should be fine, right?
But it's not and when people quip well you should have pegged your versions it's like what? Maybe you shouldn't have broke backwards compat?
Breaking change is the only thing I want to know about so realistically I only need to worry about major version updates right?
So lib: 1.* Should be fine, right?
But it's not and when people quip well you should have pegged your versions it's like what? Maybe you shouldn't have broke backwards compat?
You assume software is perfect and people don't make mistake. Breaking compat on accident happens. Bad pushes and releases exist. Unpatched bugs in latest. Wrong deployments.
Semver make it easier to spot/prevent mistakes by giving you more granular information. It's not like it's a data overload, so "too much info" as argument is really weird.
Purity in computing is a terrible master.
Semver make it easier to spot/prevent mistakes by giving you more granular information. It's not like it's a data overload, so "too much info" as argument is really weird.
Purity in computing is a terrible master.
> Breaking compat on accident happens.
Semver would be what? Tests should catch it. Mine or yours.
> Bad pushes and releases exist.
Semver would be what? Tests should catch it. Mine or yours.
> Unpatched bugs in latest.
Semver would be what? Tests should catch it. Mine or yours.
> Wrong deployments.
Semver would be what? Tests should catch it. Mine or yours.
> Semver make it easier to spot/prevent mistakes by giving you more granular information.
None of those things are fixed by semver. What is the point of semver again?
The only thing I, as a user, give any crap about is breaking change. i.e. major version numbers.
So why not just have one or two levels?
Semver would be what? Tests should catch it. Mine or yours.
> Bad pushes and releases exist.
Semver would be what? Tests should catch it. Mine or yours.
> Unpatched bugs in latest.
Semver would be what? Tests should catch it. Mine or yours.
> Wrong deployments.
Semver would be what? Tests should catch it. Mine or yours.
> Semver make it easier to spot/prevent mistakes by giving you more granular information.
None of those things are fixed by semver. What is the point of semver again?
The only thing I, as a user, give any crap about is breaking change. i.e. major version numbers.
So why not just have one or two levels?
One level is great and enough.
Version X is nice.
Oh you care about breaking changes? Ok then for you we will have two levels. Version X.Y it is. For the person above that doesn't care about breaking, two levels still work.
What? You want to show your audience/clients/users that an update contains something interesting for them like a feature, and separate it from a simple typo-fix release? I guess we are adding another level then. Version X.Y.Z is here.
You see, semver is not the ideal way for everyone, but it's the way that everyone can use as they want. As a receiver of a version, you can care about if it's a feature or no, breaking or no, and you set your requirement to a specific number, or ^a number or ~a number etc. As a creator of a version, in order for everyone to work with semver the way they like it, we should be good citizens and try to signify what this version has. Even if you don't care about breaking changes or showing if you just added a feature, try to signify it in your version string. It will help someone.
Oh you care about breaking changes? Ok then for you we will have two levels. Version X.Y it is. For the person above that doesn't care about breaking, two levels still work.
What? You want to show your audience/clients/users that an update contains something interesting for them like a feature, and separate it from a simple typo-fix release? I guess we are adding another level then. Version X.Y.Z is here.
You see, semver is not the ideal way for everyone, but it's the way that everyone can use as they want. As a receiver of a version, you can care about if it's a feature or no, breaking or no, and you set your requirement to a specific number, or ^a number or ~a number etc. As a creator of a version, in order for everyone to work with semver the way they like it, we should be good citizens and try to signify what this version has. Even if you don't care about breaking changes or showing if you just added a feature, try to signify it in your version string. It will help someone.
Sometimes breaking backwards compatibility is necessary. For example, if a function in a standard library has an error case that the initial version ignored (happened in Go), you can't start emitting errors when you used to guarantee that it wouldn't error. Or if there's a fundamental flaw in a function that cannot be fixed without a signature change.
People ignore deprecation warnings, so the best way forward is often to break compatibility.
I agree that breaking compatibility should be avoided, but it shouldn't be completely out of the question. It needs to be frequent enough that your anticipate it, but not so frequent that you lose users. And you should try to have a bridge between old and new versions (e.g. Rust's "editions" seem like a good idea).
People ignore deprecation warnings, so the best way forward is often to break compatibility.
I agree that breaking compatibility should be avoided, but it shouldn't be completely out of the question. It needs to be frequent enough that your anticipate it, but not so frequent that you lose users. And you should try to have a bridge between old and new versions (e.g. Rust's "editions" seem like a good idea).
Then it should be a major version change, right?
> People ignore deprecation warnings, so the best way forward is often to break compatibility.
People don't ignore deprecation warnings, they vehemently disagree with their existence. Why the fuck are you taking functionality away from me?
Don't like your thing? Make a new one. The old one isn't hurting you. And if it is, make a new one.
> the best way forward is often to break compatibility.
This is NEVER the best way forward, this is some next level idiotic shit.
> I agree that breaking compatibility should be avoided, but it shouldn't be completely out of the question.
Why not? What in your world view makes this OK? I'm using your software because it solves a problem. I'm not using it so you can make more work for me.
If linux can make backwards compat guarantees since 0.1 then so can libraries like leftpad.
> It needs to be frequent enough that your anticipate it, but not so frequent that you lose users.
Jesus christ, if you think of your users like this I don't think you really deserve them. Your users are why your thing exists, be grateful and stop shitting on their needs for stability.
People don't ignore deprecation warnings, they vehemently disagree with their existence. Why the fuck are you taking functionality away from me?
Don't like your thing? Make a new one. The old one isn't hurting you. And if it is, make a new one.
> the best way forward is often to break compatibility.
This is NEVER the best way forward, this is some next level idiotic shit.
> I agree that breaking compatibility should be avoided, but it shouldn't be completely out of the question.
Why not? What in your world view makes this OK? I'm using your software because it solves a problem. I'm not using it so you can make more work for me.
If linux can make backwards compat guarantees since 0.1 then so can libraries like leftpad.
> It needs to be frequent enough that your anticipate it, but not so frequent that you lose users.
Jesus christ, if you think of your users like this I don't think you really deserve them. Your users are why your thing exists, be grateful and stop shitting on their needs for stability.
> Don't like your thing? Make a new one. The old one isn't hurting you. And if it is, make a new one.
That is literally what a version is.
That is literally what a version is.
Yea except you lock your users at an old version, for what?
Are you supporting old versions?
You don't have to break backwards compat to release new stuff.
It takes some serious design flaws to create a situation where you need more than a handful of foo2 and foo can't be augmented with sane defaults for whatever new side effect is created by foo2.
Are you supporting old versions?
You don't have to break backwards compat to release new stuff.
It takes some serious design flaws to create a situation where you need more than a handful of foo2 and foo can't be augmented with sane defaults for whatever new side effect is created by foo2.
Support for the old version comes in minor/patch releases.
> you simply rename
That sounds like an awful idea that will result in people adding version information to the name, not to mention destroying discoverability.
That sounds like an awful idea that will result in people adding version information to the name, not to mention destroying discoverability.
It seems like in this case you want to version API and program separately. API changes aren't the only thing people care about or that should be communicated in a version number. So semver would not just be "not perfect" but be actively misleading.
Then have a semver for the two different parts.
Ie “version 3.3.1 of Awesome Server supporting the 2.x api as well as 3.1.x”
Ie “version 3.3.1 of Awesome Server supporting the 2.x api as well as 3.1.x”
I've seen this happen with Babel a few times. They've released bugfix releases which fixed a slightly incorrect implementation of a spec, which ended up breaking loads of peoples builds (this was before npm/yarn had a decent way to lock dependencies). Turns out, compilers have a really high bar for what can be considered a non-breaking change.
Generally though, I think for end user software, a "breaking" change is one that requires the user to relearn something, i.e it breaks an existing mental model.
Generally though, I think for end user software, a "breaking" change is one that requires the user to relearn something, i.e it breaks an existing mental model.
For a standardized language like SQL you don't have API incompatibility.
Yet a cost based optimiser may break your application, completely.
Calendar Versioning prompts to update and highlights that you should test the behaviour every time, which sounds about right.
Also even a patch release of a SemVer library is allowed to be runtime incompatible. Throwing an exception on incorrect usage is down to the patch definition. It fixes incorrect (undefined) behaviour. Going from a O(1) to. O(n²) implementation to fix behaviour is also within SemVer patch level.
SemVer does not guarantee that your code will continue to work as intended after an upgrade. It only guarantees you don't have to change your code between minor versions.
Yet a cost based optimiser may break your application, completely.
Calendar Versioning prompts to update and highlights that you should test the behaviour every time, which sounds about right.
Also even a patch release of a SemVer library is allowed to be runtime incompatible. Throwing an exception on incorrect usage is down to the patch definition. It fixes incorrect (undefined) behaviour. Going from a O(1) to. O(n²) implementation to fix behaviour is also within SemVer patch level.
SemVer does not guarantee that your code will continue to work as intended after an upgrade. It only guarantees you don't have to change your code between minor versions.
They also mention in the article how they don't support skipping releases, so it sounds like you have to upgrade to each point release anyway?
Really if you're not constantly updating dependencies as part of your pipelines, you're going to quickly get into dependency rot issues.
Really if you're not constantly updating dependencies as part of your pipelines, you're going to quickly get into dependency rot issues.
I'm always surprised at how often developers freeze a set of versions and leave them for a lifetime. In my past three companies I have been the only one interested in pushing dependencies on a regular basis. I always start with a massive backlog, and end up having to incrementally update from the Stone Age to $today. Once that's set and tests pass it's easy to keep things up-to-date, you end up with single-digit changes every month instead of ~100 every year.
Do it this way and save yourself the pain of zillions of updates when you HAVE to bump a package for a CVE.
Do it this way and save yourself the pain of zillions of updates when you HAVE to bump a package for a CVE.
Yet another case of "if it hurts, do it more often"
https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...
https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...
But the journey from A to B to C to D is longer than A to D.
You can get whiplash from conforming to every change in the winds.
You can get whiplash from conforming to every change in the winds.
This. Skipping B and C needs to be managed like any other technical debt, but it can pay off. It's not your job to regression test every intermediate version of everyone's libraries.
Word! And same for me at new jobs. I also tend to be the one who writes docs, gets testing automated, CI.
Too many developers think banging out code as fast as they can is "doing their job well".
Too many developers think banging out code as fast as they can is "doing their job well".
They could have picked Android's versioning scheme : a codename to signal significance and an API level to signal compatibility.
This right here. The only reason people observe tension between semantic versioning and romantic versioning is because prior to semantic versioning we spent decades conflating the version number to convey both "important new feature" and "incompatible changes". Both user marketing and technical compatibility guidance are important, but there's nothing that inherently says that both of these things need to be communicated via a single version number. Pick a nice-sounding word to market your version with big changes, and leave it unrelated to your API version.
>The calender version 19.1 tells me nothing other than when it was released, which is of no interest whatsoever when evaluating what it does.
Old is bad, new is good. What else is there to understand?
Old is bad, new is good. What else is there to understand?
"You now have Chrome/Firefox 277, which is different from version 276, and has installed itself. Deal with it, because there's no option to revert to version 276." That's just how software works these days.
> Since we release on a 6 month cadence, we’re starting to name releases by season and year, which means our next release is now CockroachDB Spring ‘19.
Ugh. You'd think the creators of a multiregion database would realise half the planet has Autumn the same time as the other half has Spring.
> It also eliminates the mental gymnastics needed to figure out how old a release is
I guess not.
Ugh. You'd think the creators of a multiregion database would realise half the planet has Autumn the same time as the other half has Spring.
> It also eliminates the mental gymnastics needed to figure out how old a release is
I guess not.
Best thing about moving to the US was that all those phrases "coming summer 2019" actually make sense! In Australia we don't really use seasons as references (the seasons aren't as distinct as they are here) - and because they were then flipped as well I never really thought they had a real meaning.
I guess I must have known they did have a real meaning, but my "consumer" grasp of them was more like vague marketing fluff that meant "will probably be out eventually"!
I guess I must have known they did have a real meaning, but my "consumer" grasp of them was more like vague marketing fluff that meant "will probably be out eventually"!
What a brilliant observation, I love finding things like that where you never really thought consciously about something.
I'm similar to you, though I don't even have the excuse of living with different seasons - I just never really thought about it.
I'm similar to you, though I don't even have the excuse of living with different seasons - I just never really thought about it.
As an also-Australian, my brain just doesn’t process seasons like Americans.
If someone says “coming in the Spring” I literally have no idea when that is. The dates of seasons are meaningless.
If someone says “coming in the Spring” I literally have no idea when that is. The dates of seasons are meaningless.
As a Polish person, my brain hates these too, even though we have proper seasons here. When I see "coming in the Spring", my mind is all "that's 20-ish of March, I think... or maybe April... no, December is definitely winter, so it must be March!".
Seasons are dumb. I remember reading a rant on the Internet once that advocated that we should recognize two seasons - summer and winter. You could put the boundary at equinoxes, with summer encompassing both traditional summer and spring, and winter encompassing traditional autumn and winter. The definition would be simple: summer is when it's kind of warm most of the time, winter is when it's kind of cold most of the time. I remember this resonating with me much more than the traditional definition.
Going back to temporal coordinates, the older I get the more confident I am in feeling that, for terrestrial use, anything that's not an ISO 8601 date is garbage and should not be used.
Seasons are dumb. I remember reading a rant on the Internet once that advocated that we should recognize two seasons - summer and winter. You could put the boundary at equinoxes, with summer encompassing both traditional summer and spring, and winter encompassing traditional autumn and winter. The definition would be simple: summer is when it's kind of warm most of the time, winter is when it's kind of cold most of the time. I remember this resonating with me much more than the traditional definition.
Going back to temporal coordinates, the older I get the more confident I am in feeling that, for terrestrial use, anything that's not an ISO 8601 date is garbage and should not be used.
> and winter encompassing traditional autumn and winter. The definition would be simple: summer is when it's kind of warm most of the time, winter is when it's kind of cold most of the time.
At least in the part of the US I'm from, we only used "Fall" for "Autumn", because colloquially it was already defined as a simple and pretty tight (but often slightly different each year) period: When the leaves on trees have changed color, but not yet all fallen off.
At least in the part of the US I'm from, we only used "Fall" for "Autumn", because colloquially it was already defined as a simple and pretty tight (but often slightly different each year) period: When the leaves on trees have changed color, but not yet all fallen off.
[deleted]
Not only that, but the seasons have different meanings to different people depending on where in the USA you live. In my hot and desert climate spring means late February, but in Minnesota it could mean mid-May.
When you see a season mentioned in American marketing it basically means they have no idea. If a company says "spring 2019" it could mean sometime in April, or on June 20, hours before the summer solstice.
When you see a season mentioned in American marketing it basically means they have no idea. If a company says "spring 2019" it could mean sometime in April, or on June 20, hours before the summer solstice.
A side note on country differences:
A JPL intern from Spain basically told me that the day end when sunset in Spain, it's very easy there. In California sunset can be around 5 pm and that's too weird for her. From the a quick google look, it seems like Spain daylight start from 6am or 7am and end around 8 or 9 pm. It's super interesting.
A JPL intern from Spain basically told me that the day end when sunset in Spain, it's very easy there. In California sunset can be around 5 pm and that's too weird for her. From the a quick google look, it seems like Spain daylight start from 6am or 7am and end around 8 or 9 pm. It's super interesting.
Well Spain's time is a bit weird because they use CET which is most appropriate for like Sweden and the Czech Republic and the countries slightly east or west of them. Even France's use of CET is more about integration with their eastern neighbors than about having the sun the highest at 12 pm.
Apologies for being pedantic, but nearly 90% of the world's population lives in the Northern Hemisphere, which also holds most of the land as well.
I'd say they're only 10% off
I'd say they're only 10% off
Great except a bunch of places are tropical and thus don’t have four seasons as you experience it.
Thailand technically has three and people only really reference one (“winter”)
Also, I know “summer” means you get more leeway on when to actually release but is “mid year” or “late 2019” or “around November” really that hard, especially given that from what I hear, your seasons all start on weird dates?? (In Australia seasons officially start on the first of a given month)
Thailand technically has three and people only really reference one (“winter”)
Also, I know “summer” means you get more leeway on when to actually release but is “mid year” or “late 2019” or “around November” really that hard, especially given that from what I hear, your seasons all start on weird dates?? (In Australia seasons officially start on the first of a given month)
India officially has four seasons, but they are winter, summer, monsoon and post-monsoon (autumn). Depending on the place, the year may also have six seasons of two months each. [1] In general conversations, you may find people talking about summer and winter, with a sprinkling of rainy season, and not much about others.
So any definition that goes by some restricted American version (as pointed out by people living in the U.S. here) of seasons is not really applicable to 90% of the world's population. As you dig deeper into the climate of different countries, states/provinces, regions, etc., you may probably find your 90% figure drop to 10% or less.
[1]: https://en.wikipedia.org/wiki/Climate_of_India#Seasons
So any definition that goes by some restricted American version (as pointed out by people living in the U.S. here) of seasons is not really applicable to 90% of the world's population. As you dig deeper into the climate of different countries, states/provinces, regions, etc., you may probably find your 90% figure drop to 10% or less.
[1]: https://en.wikipedia.org/wiki/Climate_of_India#Seasons
Hemispherically true, though if you live near the equator, I don't think you have these kinds of seasons.
I think IntelliJ's 20XX.X model works great. Sequester big changes for annual upgrades and introduce minor features throughout the year.
> > Since we release on a 6 month cadence, we’re starting to name releases by season and year, which means our next release is now CockroachDB Spring ‘19.
> Ugh. You'd think the creators of a multiregion database would realise half the planet has Autumn the same time as the other half has Spring.
The season name will only be produced in marketing materials mainly targeting North America and Europe. The technical product will be named "19.1". The season name will not appear in an install.
> Ugh. You'd think the creators of a multiregion database would realise half the planet has Autumn the same time as the other half has Spring.
The season name will only be produced in marketing materials mainly targeting North America and Europe. The technical product will be named "19.1". The season name will not appear in an install.
> in marketing materials mainly targeting North America and Europe
Except that the rest of the world sees the exact same internet and the services are available online through the world wide web, something anybody from anywhere (barring cenorship) can see.
Even if Cockroach Labs delivers a different website to people outside North America and Europe that don't reference the seasons, the rest of the world will still manage to happen upon either those materials of other people who reference the naming scheme used by those materials.
Why not save the hassle and just not bother with the season naming at all? There's enough evidence from the comment section to show such a scheme was insufficiently thought through for an internationally-available product available online that likely has an international community of users who will very likely chat amongst themselves, referencing marketing material not intended for everybody's consumption.
Except that the rest of the world sees the exact same internet and the services are available online through the world wide web, something anybody from anywhere (barring cenorship) can see.
Even if Cockroach Labs delivers a different website to people outside North America and Europe that don't reference the seasons, the rest of the world will still manage to happen upon either those materials of other people who reference the naming scheme used by those materials.
Why not save the hassle and just not bother with the season naming at all? There's enough evidence from the comment section to show such a scheme was insufficiently thought through for an internationally-available product available online that likely has an international community of users who will very likely chat amongst themselves, referencing marketing material not intended for everybody's consumption.
Half the planet, but 90% of population, and probably 95% of users.
I think the problem isn't the % of population that lives in a particular hemisphere, it's that the seasonal versioning scheme forces you to think about which hemisphere the software was created in. I'd say most users of an open source database would be aware that there is software being written in South Africa, Australia, New Zealand etc.
That logic only works when something like month doesn't.
I'm not conding the spring/summer naming (personally I'd just leave it at january/june), but the bulk of the world's population lives in the northern hemisphere, and not by a little, by a lot.
http://www.radicalcartography.net/index.html?histpop
http://www.radicalcartography.net/index.html?histpop
Who cares unless literally all of them do.
Just adding context in case people thought the populations were roughly equivalent. It has bearing in the validity of choosing something the majority of people would understand.
For the same reason that software documentation is almost always in English.
Probably looking a bit too much at salesforce
It's not actually called Spring '19 mentioned later in the article: 19.1, 19.2, 19.2.1 (patch).
Just read it as 1st or 2nd semester. Works in all hemispheres
This isn't a university - what the hell is a semester?
University semesters are also out of phase between the hemispheres. 1st semester is ~late summer/early autumn for both.
In NZ, first semester starts near the end of February. Second starts early July.
This feels like the "product version" has taken over again.
I promote semver internally primarily for wiring together build automation. But I also try to make it clear that there can be a _completely different_ "product version" that can mean whatever the hell we want it to be. Calendar versions are great product versions.
Many people, frequently product managers, are very uncomfortable with this distinction.
So many places use the product version as "the version", which then becomes the main justification for monolithic version control, even for distributed applications or multiple product lines. So now, you re-build and/or re-deploy everything, even things that had no changes, purely to stay in sync with "the version".
There are usually good _technical_ reasons for monolithic version control, but doing it just to slap a product version on everything usually ends up with an alarming amount of waste.
I promote semver internally primarily for wiring together build automation. But I also try to make it clear that there can be a _completely different_ "product version" that can mean whatever the hell we want it to be. Calendar versions are great product versions.
Many people, frequently product managers, are very uncomfortable with this distinction.
So many places use the product version as "the version", which then becomes the main justification for monolithic version control, even for distributed applications or multiple product lines. So now, you re-build and/or re-deploy everything, even things that had no changes, purely to stay in sync with "the version".
There are usually good _technical_ reasons for monolithic version control, but doing it just to slap a product version on everything usually ends up with an alarming amount of waste.
This!
Semver uses the version number to convey useful information. Getting rid of semver just eliminates that information.
If you want to bump versions for marketting, that's perfectly valid. Just use a separate product version.
My SVN commit numbers and git hashes also fail to convey useful marketting information, but that's no reason to get rid of them!
Semver uses the version number to convey useful information. Getting rid of semver just eliminates that information.
If you want to bump versions for marketting, that's perfectly valid. Just use a separate product version.
My SVN commit numbers and git hashes also fail to convey useful marketting information, but that's no reason to get rid of them!
This. The tension in the OA sounds like people a conflating sales marketing based product number and the engineering based version.
Keep those separate or have constant missunderstandings, arguments, and frustration. Sadly, I talk from experience.
Keep those separate or have constant missunderstandings, arguments, and frustration. Sadly, I talk from experience.
I wish this was built into semver as the first field.
Seems like most folks here are missing the really interesting part about the article:
> But was this enough of a value jump to merit the leap to 3.0?
Semver said nothing about "value". Semver only talks about breaking changes and added functionality vs. purely fixing bugs. For many users and libraries this is more than sufficient, because it allows you to manage risk when upgrading. However, lets enter some false preconceptions and more importantly Enterprise:
False preconceptions: Historically major versions of software, pre-semver, had major new features. Many people still have the expectation that this will be the case. This still gets reinforced by many software products (as opposed to libraries). We'd all be surprised if Apple released a new iOS major version and it has no new significant features, but just breaks some APIs that had been deprecated. This is what server would dictate, but would break human expectations.
Enterprise: I am sure CockroachDB has support contracts with some larger companies. What are the terms? Are there some support durations that are based on major version numbers? Now majors aren't free anymore. Even if their support contracts don't care about major vs minors, you want your customers to upgrade ASAP, because the older the version you have to support, the more different is that code base from what you are actively working on and the fewer other customers will benefit. A fix on your latest version will likely be with the product forever, whereas a fix on a version that's three years old might not even be relevant to your latest. A major release in server has per definition breaking changes. So this won't be a zero-cost upgrade. Many enterprises in addition have much heavier procedures to upgrade a major dependency, especially for something like a database. This makes for a lot of reason not to upgrade. So now you need some very good carrots to get users to upgrade.
Even if you don't have paying customers, breaking changes without a big carrot can be a problem. Nobody wants a mess like Python 2.7 vs. 3.
It seems like CockroachLabs just has passage of time make the decision for them now. I'd be very curious to see how this will impact how far behind latest their customers will be.
False preconceptions: Historically major versions of software, pre-semver, had major new features. Many people still have the expectation that this will be the case. This still gets reinforced by many software products (as opposed to libraries). We'd all be surprised if Apple released a new iOS major version and it has no new significant features, but just breaks some APIs that had been deprecated. This is what server would dictate, but would break human expectations.
Enterprise: I am sure CockroachDB has support contracts with some larger companies. What are the terms? Are there some support durations that are based on major version numbers? Now majors aren't free anymore. Even if their support contracts don't care about major vs minors, you want your customers to upgrade ASAP, because the older the version you have to support, the more different is that code base from what you are actively working on and the fewer other customers will benefit. A fix on your latest version will likely be with the product forever, whereas a fix on a version that's three years old might not even be relevant to your latest. A major release in server has per definition breaking changes. So this won't be a zero-cost upgrade. Many enterprises in addition have much heavier procedures to upgrade a major dependency, especially for something like a database. This makes for a lot of reason not to upgrade. So now you need some very good carrots to get users to upgrade.
Even if you don't have paying customers, breaking changes without a big carrot can be a problem. Nobody wants a mess like Python 2.7 vs. 3.
It seems like CockroachLabs just has passage of time make the decision for them now. I'd be very curious to see how this will impact how far behind latest their customers will be.
Why not just move to 3.0?
Semver only says that a breaking change MUST be an increase to the major version. It doesn't proscribe an increase of the major version without a breaking change.
Yes! Semver is very precisely specified and the specification ain't very long. How on Earth could they mess it up?
Because its summary does not exactly agree to the specification.
> 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.
> 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.
A point not highlighted in OP article is that Enterprise customers are shy to upgrade to a "next major version" because they will _assume_ there are breaking changes in there (even though semver allows bumping the major number without breaking changes).
Calver side-steps this user bias.
Calver side-steps this user bias.
Why are developers always insistent on trying to trick the user into doing what they want them to do, or what they think is best, instead of letting users do what users want to do?
Users shy away from major version numbers because they are allowed to change things in incompatible ways. When you jump a major version you're signaling that stuff might intentionally break, and they make their decisions accordingly. The solution is not to make your communication with user even worse!
Users shy away from major version numbers because they are allowed to change things in incompatible ways. When you jump a major version you're signaling that stuff might intentionally break, and they make their decisions accordingly. The solution is not to make your communication with user even worse!
This could easily be solved by something along the lines of “Version 3.0 maintains full compatibility with Version 2.2” at the top of their release notes.
I dislike the idea of going away from SemVer just for marketing purposes. At least as a user when I’m going to upgrade versions then I could see that “oh, this version doesn’t break compatibility”
I dislike the idea of going away from SemVer just for marketing purposes. At least as a user when I’m going to upgrade versions then I could see that “oh, this version doesn’t break compatibility”
>Calver side-steps this user bias.
Well, no, it just means users won't update at all, because every version could be breaking...
Well, no, it just means users won't update at all, because every version could be breaking...
> helps us (and our users) avoid the confusion around the significance of a release.
I think you mean "makes it impossible to know if a release includes backwards incompatible changes without looking at the release notes, while still having a release number say nothing about other aspects of the significance of a release."
I think you mean "makes it impossible to know if a release includes backwards incompatible changes without looking at the release notes, while still having a release number say nothing about other aspects of the significance of a release."
> I think you mean "makes it impossible to know if a release includes backwards incompatible changes without looking at the release notes, while still having a release number say nothing about other aspects of the significance of a release."
The compatibility guarantees of CockroachDB do not change with this. It's always been the same: version X+1 will remain backward compatible with X but may break compatibility with X-1. Deprecation notices for definitive changes in version X+2 are introduced in version X.
The compatibility guarantees of CockroachDB do not change with this. It's always been the same: version X+1 will remain backward compatible with X but may break compatibility with X-1. Deprecation notices for definitive changes in version X+2 are introduced in version X.
> version X+1 will remain backward compatible with X but may break compatibility with X-1
That is literally impossible; a breaking change from X-1 to X+1 must have been introduced in one of the intervals X-1 to X or X to X+1. It the latter, X+1 breaks compatibility, if the former, let X' = X-1 and X'+1 breaks compatibility.
Presumably you mean that X always includes warnings about breaking changes in X+1, which is a vast improvement on some projects, but knowing that a problem exists doesn't mean it doesn't exist.
That is literally impossible; a breaking change from X-1 to X+1 must have been introduced in one of the intervals X-1 to X or X to X+1. It the latter, X+1 breaks compatibility, if the former, let X' = X-1 and X'+1 breaks compatibility.
Presumably you mean that X always includes warnings about breaking changes in X+1, which is a vast improvement on some projects, but knowing that a problem exists doesn't mean it doesn't exist.
> That is literally impossible; a breaking change from X-1 to X+1 must have been introduced in one of the intervals X-1 to X or X to X+1. It the latter, X+1 breaks compatibility, if the former, let X' = X-1 and X'+1 breaks compatibility.
No, that's not how it works. The deprecation is introduced in version X-1; the new behavior is introduced but is opt-in; in version X, the new behavior becomes opt-out; in version X+1 the old behavior is removed.
No, that's not how it works. The deprecation is introduced in version X-1; the new behavior is introduced but is opt-in; in version X, the new behavior becomes opt-out; in version X+1 the old behavior is removed.
That breaks backwards compatibility twice; once in X when 'do_thing' breaks and has to be rewritten as 'enable_thing;do_thing', then again when X+1 causes 'enable_thing;do_thing' to break.
Yes, it means X+1 is backwards compatible with X so long as no deprecation notices were produced by your use in X. I get it, and find it reasonable.
Seems to be a few critics in here but I think a good usecase for calendar versioning is crypto and security critical libraries.
You hear about about WPA3 being broken in April 2019. It's obvious your WPA3 18.10 lib is vulnerable, WPA3 19.04 is not.
It's a lot simpler to parse and can lead to less mistakes.
You hear about about WPA3 being broken in April 2019. It's obvious your WPA3 18.10 lib is vulnerable, WPA3 19.04 is not.
It's a lot simpler to parse and can lead to less mistakes.
Is it just me or are you implying WPA3 revisions should be coupled to Ubuntu release schedule?
Decoupling feature releases from API changes is the best option. Your API follows strict semver, but your new features can use whatever versioning scheme you want, this date-based scheme is fine.
So the new version is 19.1 [API 2.2].
Most of this thread is debating the relative value of using a single number to communicate feature additions vs breaking changes, but these two things are (mostly) orthogonal. So use two numbers. This even allows releases where there are awesome new features but no API changes at all!
So the new version is 19.1 [API 2.2].
Most of this thread is debating the relative value of using a single number to communicate feature additions vs breaking changes, but these two things are (mostly) orthogonal. So use two numbers. This even allows releases where there are awesome new features but no API changes at all!
The main reason I don't like timestamp based version schemes is that it makes builds inherently difficult to reproduce.
I wrote some code for a specialized piece of equipment earlier this year. One of the requirements on this equipment is that all package installs contain a unique version string (ie. you can't install the same version twice). So I based build versions on git hash and timestamp. This turned out to be a problem because it made it impossible to reproduce builds without hacking the build system clock. So I switched back to semver for releases.
I wrote some code for a specialized piece of equipment earlier this year. One of the requirements on this equipment is that all package installs contain a unique version string (ie. you can't install the same version twice). So I based build versions on git hash and timestamp. This turned out to be a problem because it made it impossible to reproduce builds without hacking the build system clock. So I switched back to semver for releases.
Build systems can (and should) read $SOURCE_DATE_EPOCH if it's set, and fallback to the system/CVS time otherwise.
$SOURCE_DATE_EPOCH was created exactly for your use case. https://reproducible-builds.org/docs/source-date-epoch/
$SOURCE_DATE_EPOCH was created exactly for your use case. https://reproducible-builds.org/docs/source-date-epoch/
calver != timestamp version
calver has a number picked up when the release is produced, not when the build is run.
calver has a number picked up when the release is produced, not when the build is run.
What is the point of a reproducible build if you need to rebuild it to test its the same?
The entire point of a reproducible build is that you can rebuild it to test that it's the same.
No.. the entire point of a reproducible build is so that you can rebuild the same thing given the same inputs across the world different servers.
Testing that md5sum(software A) works just like md5sum(software A) is just pointless?
Testing that md5sum(software A) works just like md5sum(software A) is just pointless?
Why not simply separate versioning into product and technical like Microsoft Visual Studio as an example:
Product version: Visual Studio 2019
Technical version: 16.0.1
It fits good for marketing and for developer people.
It fits good for marketing and for developer people.
Because it causes even more confusion. Given a Windows 10 version number like 10.0.16299.522, you need a lookup table to determine that it is called 1709 by all the documentation.
Just so you know, season based names make no sense since the Southern Hemisphere exists.
Also there’s no such thing as Fall in a lot of places.
Also there’s no such thing as Fall in a lot of places.
As an Australian, "Coming Summer 2019" may as well just say "Coming 2019".
I don't care to research the country of the developer and then the dates that are considered summer in that country just because they were so ignorant they used a season as a timeframe.
I don't care to research the country of the developer and then the dates that are considered summer in that country just because they were so ignorant they used a season as a timeframe.
I feel like a lot of semver purists have never maintained software with a lot of downstream dependencies. The gray area about what is a breaking change is huge and it's hard to usefully improve software without making changes that are breaking under some definitions. The broadest is that, if a downstream program was working against version x.y, then it should always work unmodified against x.z.
One obvious case is bug compatibility and undocumented behaviour - it isn't that uncommon for software to depend on bugs or undocumented/unintentional behaviour. But if you're exposing a language like SQL, it's even messier. E.g. if cockroach added a new feature to the SQL dialect, then it could break downstream software that was assuming a particular SQL string would return an error. Or if you extend existing functionality, say supporting a wider range of arguments in some function.
There's also unspecified behaviour and implementation details - e.g. if a query without an "order by" happened to reliably return rows in a particular order before an upgrade, but it changes after an upgrade because of an algorithmic change, is it a breaking change? Common sense would say no, because it's not documented behaviour, but pedants could disagree.
And of course there's performance changes - if a query runs 100x slower after an upgrade, but returns the same result, is that a breaking change?
If you take the most pedantic interpretation of semver, you either have to bump the major version number all the time or you are very limited in how you can improve the software.
One obvious case is bug compatibility and undocumented behaviour - it isn't that uncommon for software to depend on bugs or undocumented/unintentional behaviour. But if you're exposing a language like SQL, it's even messier. E.g. if cockroach added a new feature to the SQL dialect, then it could break downstream software that was assuming a particular SQL string would return an error. Or if you extend existing functionality, say supporting a wider range of arguments in some function.
There's also unspecified behaviour and implementation details - e.g. if a query without an "order by" happened to reliably return rows in a particular order before an upgrade, but it changes after an upgrade because of an algorithmic change, is it a breaking change? Common sense would say no, because it's not documented behaviour, but pedants could disagree.
And of course there's performance changes - if a query runs 100x slower after an upgrade, but returns the same result, is that a breaking change?
If you take the most pedantic interpretation of semver, you either have to bump the major version number all the time or you are very limited in how you can improve the software.
I never found stric following of semantic versioning to be a good fit for product versions. It makes sense only for libraries and packages.
Why not?
Because a backward incompatible change can be required to implement a small feature or even fix a bug, which does not justify major version bump from the production life cycle perspective.
What about the "production life cycle perspective" requires that major version numbers not bump in those cases?
If version pattern is thought of as "compatibility.feature.fix" then there is no reason that feature and fix changes cannot also bump the right most number [as compatibility is broken].
EDIT: for clarity
If version pattern is thought of as "compatibility.feature.fix" then there is no reason that feature and fix changes cannot also bump the right most number [as compatibility is broken].
EDIT: for clarity
> What about the "production life cycle perspective" requires that major version numbers not bump in those cases?
Let's say you just finished a big campaign, promoting the new major version of the software (e.g. 2.0) to customers. After starting with rollout, couple of weeks down the line shit happens (it does happen) and you realise you have a bug, which you can only fix by introducing backward incompatibility and providing e.g. a migration tool to apply the fix and migrate data.
Now according to semver you would have to release version 3.0 with basically one change, which is something that product management will not accept (and rightly so), because next big release and marketing campaign would have to be for version 4.0, and customers will ask "what the heck happened with version 3.0".
Long story short, semver is "too automatic" to fit in product management, but it is a good fit for package managers and libraries where this is less obvious to the end user.
Let's say you just finished a big campaign, promoting the new major version of the software (e.g. 2.0) to customers. After starting with rollout, couple of weeks down the line shit happens (it does happen) and you realise you have a bug, which you can only fix by introducing backward incompatibility and providing e.g. a migration tool to apply the fix and migrate data.
Now according to semver you would have to release version 3.0 with basically one change, which is something that product management will not accept (and rightly so), because next big release and marketing campaign would have to be for version 4.0, and customers will ask "what the heck happened with version 3.0".
Long story short, semver is "too automatic" to fit in product management, but it is a good fit for package managers and libraries where this is less obvious to the end user.
> Let's say you just finished a big campaign, promoting the new major version...
Again, this sounds like a marketing concern. A software or service need not be marketed by the technical version. As mentioned elsewhere Java famously promotes it's dot version and is famously maintains backwards compatibility to v1.0, IIRC.
Consider that a business consuming software and services is not only concerned with the market version/edition but their IT very much cares about the technical version and what each release communicates. Windows has an internal version number besides the ME, XP, Vista bullshit.
Again, this sounds like a marketing concern. A software or service need not be marketed by the technical version. As mentioned elsewhere Java famously promotes it's dot version and is famously maintains backwards compatibility to v1.0, IIRC.
Consider that a business consuming software and services is not only concerned with the market version/edition but their IT very much cares about the technical version and what each release communicates. Windows has an internal version number besides the ME, XP, Vista bullshit.
> If version pattern is thought of as "compatibility.feature.fix" then there is no reason that feature and fix changes cannot also bump the right most number [as compatibility is broken].
We think about it as "product(Management)Version.developmentIteration.emergencyPatch".
First number is incremented only in coordination with business/PR/marketing.
Second number is incremented after every development iteration (mostly one, but sometimes multiple sprints), regardless of new features being introduced or just code stabilisation is being worked on, and regardless of it being backward compatible or not. As someone mentioned, release notes are there to communicate that part.
Third number is incremented only if we're fixing some emergency issue on one of the release branches. E.g. customer running version 4.2, reports a bug. We fix it on the branch and release 4.2.1
We think about it as "product(Management)Version.developmentIteration.emergencyPatch".
First number is incremented only in coordination with business/PR/marketing.
Second number is incremented after every development iteration (mostly one, but sometimes multiple sprints), regardless of new features being introduced or just code stabilisation is being worked on, and regardless of it being backward compatible or not. As someone mentioned, release notes are there to communicate that part.
Third number is incremented only if we're fixing some emergency issue on one of the release branches. E.g. customer running version 4.2, reports a bug. We fix it on the branch and release 4.2.1
Then you don't have SemVer but some Frankenstein combination of marketing and technical versioning. One with few advantages to traditional, arbitrary versioning which still requires IT digest every releases' changes to get a sense of the magnitude of the changes.
Not saying that's wrong for everyone. But I for one prefer versioning that clearly communicates compatibility before any marketing concerns.
Not saying that's wrong for everyone. But I for one prefer versioning that clearly communicates compatibility before any marketing concerns.
Also, major new feature, even though it is backward compatible, is a better reason for major version number increase.
In Semver the second part communicates features, not 'major'. So magnitude of the features should not matter. Unless version is more for marketing than communicating the precise nature of the changes.
That's why I'm saying semver is not a good fit for product versions. It's too technical and doesn't fit well with PR, marketing and product management.
Point taken. I'm curious if using the second/feature part of SemVer for the advertised product version would be a workable compromise?
Or must marketing always get "top billing" in that precious left-most spot?
Or must marketing always get "top billing" in that precious left-most spot?
Marketing
"But with that logic guiding the major version bump, we could potentially remain on 2.x forever."
That's WAI if you don't break compatibility.
I think the only reason behind moving is to have a better sense of progress or freshness. It seems like semantic versioning should support having some date on the minor numbers.
That's WAI if you don't break compatibility.
I think the only reason behind moving is to have a better sense of progress or freshness. It seems like semantic versioning should support having some date on the minor numbers.
Semver _allows_ non-breaking changes on major release. It also supports tagging which could be a date tag.
The entire spec is like a 10 minute read. Anyone using semver should have at least read the semver spec. Anyway, the bullet on tagging:
“Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.”
The entire spec is like a 10 minute read. Anyone using semver should have at least read the semver spec. Anyway, the bullet on tagging:
“Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.”
These decisions are often driven by marketing or product folks and rarely engineers.
The marketing team would probably even push further toward 1, 2, 3, or anything that could make a big splash once or twice a year. The product team would probably prefer dates because it makes their planning easier.
The marketing team would probably even push further toward 1, 2, 3, or anything that could make a big splash once or twice a year. The product team would probably prefer dates because it makes their planning easier.
If semver says the next version is 2.2, then it's 2.2, what discussion is there to side step?
Marketing maybe? If you are good about being backward compatible, you never release n+1, which might be mistaken for being stale vs your competitors.
“This was version 2.something when I started, I’ve been working on this for n years and it’s still version 2.something” sure sounds like a demotivating feeling to me, too.
Interesting!
If I worked on a product that was version 2.1 when I started, and 5 years later was on version 6.5 without any actual rewrites or improvements in it, I would find that just as demotivating.
If I worked on a product that was version 2.1 when I started, and 5 years later was on version 6.5 without any actual rewrites or improvements in it, I would find that just as demotivating.
If I worked on something for 5 years with no rewrites/improvements, I'd be demotivated as crap, no matter the version number...
Realistically, I think there are a lot of people working in these sorts of situations.
Such a stable environment would leave a lot of room for side projects on a stable paycheck, or getting some extracurricular qualifications.
Such a stable environment would leave a lot of room for side projects on a stable paycheck, or getting some extracurricular qualifications.
Yeah, and I've been in a similar situaton. A year in, and my wife told me I needed to get a new job cause that one was making me "depressed"
Can't marketing just focus on the minor part as Java does?
This is the real answer. Semver is a tool to keep code from breaking while communicating useful information to developers and engineers. Branding is an entirely different game, and the branding doesn't have to be machine-readable or adhere to any spec.
Marketing will, of course, do whatever they want. 3.x, 95, 98, ME, XP, NT, Vista, 7, 8, 10. Or just change the name when they want, ala macOS.
Edit: added Vista... thanks!
Edit: added Vista... thanks!
XBox -> XBox 360 -> XBox One... If the next console from Microsoft is controller that live streams games from the cloud I expect it to be called the XBox ExBox.
you forgot Vista
God forbid we have any maturity and reliability in our industry. Just tell people "We don't fix what ain't broke".
In one of the startups that I worked marketing people really wanted us to quickly go through version 1, 2 and reach version 3 because "many corporations aren't even looking at tools if they are not version 3 yet" :D They didn't really care what features should be included in those versions :) Fortunately sanity prevailed and we stayed with semver.
Trick question: was the startup successful?
Not that I agree with ditching semver, but the way you stated it actually sounds like a good argument for doing it, not against. Sometimes marketing people have a point.
Not that I agree with ditching semver, but the way you stated it actually sounds like a good argument for doing it, not against. Sometimes marketing people have a point.
The versionings are not mutually exclusive. In our company we use calver, it is used mainly for planning and business purposes and works well. During the quarter or whatever period there can be multiple semantically versioned releases made. The only problematic is the YY format choice. Lots of people confuse 19.3 with March 19th in our country.
they had the worst reason possible. "not remain on 2.x forever".
nobody cares about stability anymore. staying on 2.x by not breaking backward compatibility forever is a great feat to celebrate, sad to see marketing getting the best of it.
I personally like traditional versioning + security patches by date. but I'm on the minority.
nobody cares about stability anymore. staying on 2.x by not breaking backward compatibility forever is a great feat to celebrate, sad to see marketing getting the best of it.
I personally like traditional versioning + security patches by date. but I'm on the minority.
So, because of a hypothetical concern that semver could unnecessarily declare a non-breaking change as breaking, they got rid of non-breaking changes altogether?
This seems a pretty roundabout way to tell users they don't want to be backwards compatible anymore.
This seems a pretty roundabout way to tell users they don't want to be backwards compatible anymore.
All this means is that users will need to read changelogs to know if this update has breaking changes. A really bad move a database provider, you're the backbone of near all applications you should be rocksolid.
> how much time has elapsed between two releases
If they really wanted to communicate that clear without having to read extra docs they should have used 2019 version instead of 19.
> Our Spring ‘19
The world is big, bellow the line of the equator the seasons are opposite so that could lead to more confusion to the lower half of the planet.
In summary, whatever works for them, SemVer is not the clearly the winner in market share, so we as devs always have to check and double check when upgrading things but IMHO the arguments provided in the article are not strong enough to justify the move.
If they really wanted to communicate that clear without having to read extra docs they should have used 2019 version instead of 19.
> Our Spring ‘19
The world is big, bellow the line of the equator the seasons are opposite so that could lead to more confusion to the lower half of the planet.
In summary, whatever works for them, SemVer is not the clearly the winner in market share, so we as devs always have to check and double check when upgrading things but IMHO the arguments provided in the article are not strong enough to justify the move.
This is a hilarious coincidence, we (a database with opposite tradeoffs of Cockroach) just did the same thing a month ago:
`npm install [email protected]`
This means no breaking change.
How old/new of a version you are on.
Month+day the bug got fixed.
It was the compromise between intense debates within the community. It is the one thing everyone could agree too.
Looks like it is already catching on! I hope more projects adopt it.
`npm install [email protected]`
This means no breaking change.
How old/new of a version you are on.
Month+day the bug got fixed.
It was the compromise between intense debates within the community. It is the one thing everyone could agree too.
Looks like it is already catching on! I hope more projects adopt it.
'Spring' is a useless indicator for versioning. Most developers publish from the northern hemisphere so their Spring is March through May; mine is September through November down here in New Zealand.
Cockroach Labs should rather copy Apple's model, free of hemisphere bias: Early 20XX, Mid 20XX, Late 20XX.
Cockroach Labs should rather copy Apple's model, free of hemisphere bias: Early 20XX, Mid 20XX, Late 20XX.
An item about versioning is always a good time to revisit Rich Hickey's thoughts on growing software and his criticisms of semantic versioning.
https://www.youtube.com/watch?v=oyLBGkS5ICk
https://www.youtube.com/watch?v=oyLBGkS5ICk
Semver really isn't good for anything. Do you trust it so much you'd deploy patch increments to prod without tests? Minor increments?
I've said it before: software is too complex to be described by three numbers. Write tests and read the changelog. The version doesn't matter at all.
I've said it before: software is too complex to be described by three numbers. Write tests and read the changelog. The version doesn't matter at all.
Seems to me, there's version and there's compatibility. They are not one in the same. Trying to make a single field do double duty is so often never a good idea. Why is this any different?
Perhaps it's time to rethink this?
Perhaps it's time to rethink this?
Bad choice. If I ever build and maintain a database I am going to managethe vefsioning and releasing the way postgresql does, no need to get fancy with this, keep your user happy and not busy with distractions like this.
This is terrible imo, but does is further evidence that semver should have a fourth, non-semantic marketing prefix. Because otherwise people will do ... "things" like this.
I don’t see why these things need to be mutually exclusive.
For years I’ve released things with semantic numbering but a YYYYMMDD build number.
For years I’ve released things with semantic numbering but a YYYYMMDD build number.
Funny. Not everyone knows what "Spring" is. It's not the universal season you think it is.
Definitely year.month is superior.
Definitely year.month is superior.
It turns out semantic versioning hurts sales.
Wow, people really, really seem to care about this. Does it matter, or is this just dev wanking?
This made me respect cockroachdb less.
It’s called romantic versioning
The whole point of semver is that it allows people to know if they can upgrade version without hitting incompatibilities. So yes, this would be a 2.2 and those on 2.1 would know that they could upgrade to it without worrying about fixing their own integrations.
The calender version 19.1 tells me nothing other than when it was released, which is of no interest whatsoever when evaluating what it does. Sounds like a triumph of marketing over useful information.