51–60 of 167 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 c…
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?
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).
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.
Earlier quoted context omitted.
Yes! Semver is very precisely specified and the specification ain't very long. How on Earth could they mess it up?
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.
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!
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.
> 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.
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 f…
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.
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.
Earlier quoted context omitted.
Can't marketing just focus on the minor part as Java does?
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!
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.