You could argue for days either way. Just read the release notes and stop being lazy developers.
Why we’re switching to calendar versioning
91–100 of 167 posts
Re: Why we’re switching to calendar versioning
#92> 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.
Just read it as 1st or 2nd semester. Works in all hemispheres
In NZ, first semester starts near the end of February. Second starts early July.
Re: Why we’re switching to calendar versioning
#93> 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…
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.
Re: Why we’re switching to calendar versioning
#94Earlier quoted context omitted.
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…
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.
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.
Re: Why we’re switching to calendar versioning
#95Decoupling 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!
Re: Why we’re switching to calendar versioning
#96This is a hilarious coincidence, we (a database with opposite tradeoffs of Cockroach) just did the same thing a month ago:
`npm install gun@0.2019.413`
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.
Re: Why we’re switching to calendar versioning
#97I 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.
Re: Why we’re switching to calendar versioning
#98Earlier quoted context omitted.
“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 something for 5 years with no rewrites/improvements, I'd be demotivated as crap, no matter the version number...
Re: Why we’re switching to calendar versioning
#99> 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.
It's not actually called Spring '19 mentioned later in the article: 19.1, 19.2, 19.2.1 (patch).
Re: Why we’re switching to calendar versioning
#100This 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.