Why we’re switching to calendar versioning • Hacker News Board

Re: Why we’re switching to calendar versioning

#11

Post by lifthrasiir » Sun, Apr 14, 2019, 1:23 PM UTC

mcdee wrote: post #7

> 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 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.

Re: Why we’re switching to calendar versioning

#12

Post by egypturnash » Sun, Apr 14, 2019, 1:25 PM UTC

tyingq wrote: post #4

ses1984 wrote: post #2

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.

Re: Why we’re switching to calendar versioning

#13

Post by sametmax » Sun, Apr 14, 2019, 1:26 PM UTC

lifthrasiir wrote: post #11

mcdee wrote: post #7

> 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 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 u…

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.

Re: Why we’re switching to calendar versioning

#14

Post by dietr1ch » Sun, Apr 14, 2019, 1:28 PM UTC

"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.

Re: Why we’re switching to calendar versioning

#15

Post by jbverschoor » Sun, Apr 14, 2019, 1:28 PM UTC

jazoom wrote: post #8

> 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.

Probably looking a bit too much at salesforce

Re: Why we’re switching to calendar versioning

#16

Post by kakarot » Sun, Apr 14, 2019, 1:31 PM UTC

jazoom wrote: post #8

> 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 think IntelliJ's 20XX.X model works great. Sequester big changes for annual upgrades and introduce minor features throughout the year.

Re: Why we’re switching to calendar versioning

#17

Post by kolinko » Sun, Apr 14, 2019, 1:31 PM UTC

jazoom wrote: post #8

> 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.

Half the planet, but 90% of population, and probably 95% of users.

Re: Why we’re switching to calendar versioning

#18

Post by misterdoubt » Sun, Apr 14, 2019, 1:34 PM UTC

devmop wrote: post #5

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?

Re: Why we’re switching to calendar versioning

#19

Post by lifthrasiir » Sun, Apr 14, 2019, 1:36 PM UTC

sametmax wrote: post #13

lifthrasiir wrote: post #11

Earlier quoted context omitted.

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 u…

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.

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).

Re: Why we’re switching to calendar versioning

#20

Post by ThePadawan » Sun, Apr 14, 2019, 1:44 PM UTC

egypturnash wrote: post #12

tyingq wrote: post #4

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.

“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.