41–50 of 167 posts
Earlier quoted context omitted.
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.
Can't marketing just focus on the minor part as Java does?
Edit: added Vista... thanks!
Earlier quoted context omitted.
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.
Can't marketing just focus on the minor part as Java does?
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.
> 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."
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.
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?
> 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.
> 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…
> 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…
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.
For example I know precisely how old ubuntu 16.04 is and what I can expect to (not) be in there.
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…
calver has a number picked up when the release is produced, not when the build is run.
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…
By that interpretation, their calendar versioning (19.1.0) is also valid semver, because there's no rule about NOT just incrementing whatever whenever.
> 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.
I'd say they're only 10% off