121–130 of 167 posts
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.
Earlier quoted context omitted.
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.
Also, major new feature, even though it is backward compatible, is a better reason for major version number increase.
Earlier quoted context omitted.
> 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 NO…
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…
Earlier quoted context omitted.
> 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 NO…
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…
Earlier quoted context omitted.
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.
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…
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.
Earlier quoted context omitted.
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.
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…
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.
> 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." 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 wit…
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.
> Among other things, it includes a cost-based optimizer that can complete the TPC-H benchmark, CDC, and two major enterprise security features. But was this enough of a value jump to merit the leap to 3.0? Or was this a 2.2? Strictly following the semantic versioning rules would specify 2.2, as there are no backwards incompatible API changes. But with that logic guiding the major version bump, we could potentially r…
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.
> 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.
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
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)