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!
Why we’re switching to calendar versioning
81–90 of 167 posts
Re: Why we’re switching to calendar versioning
#82Earlier quoted context omitted.
XBox -> XBox 360 -> XBox One... If the next console from Microsoft is controller that live streams games from the cloud I expect it to be called the XBox ExBox.
And if it’s a full console, the next Xbox should be the ‘Xbox 361’. Or the ‘Xbox -359’, maybe?
Re: Why we’re switching to calendar versioning
#83Earlier 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.
Re: Why we’re switching to calendar versioning
#84The 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…
$SOURCE_DATE_EPOCH was created exactly for your use case. https://reproducible-builds.org/docs/source-date-epoch/
Re: Why we’re switching to calendar versioning
#85> 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…
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.
Re: Why we’re switching to calendar versioning
#86> 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'm not conding the spring/summer naming (personally I'd just leave it at january/june), but the bulk of the world's population lives in the northern hemisphere, and not by a little, by a lot. http://www.radicalcartography.net/index.html?histpop
Re: Why we’re switching to calendar versioning
#87> 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
Re: Why we’re switching to calendar versioning
#88Re: Why we’re switching to calendar versioning
#89Earlier quoted context omitted.
As an also-Australian, my brain just doesn’t process seasons like Americans. If someone says “coming in the Spring” I literally have no idea when that is. The dates of seasons are meaningless.
As a Polish person, my brain hates these too, even though we have proper seasons here. When I see "coming in the Spring", my mind is all "that's 20-ish of March, I think... or maybe April... no, December is definitely winter, so it must be March!". Seasons are dumb. I remember reading a rant on the Internet once that advocated that we should recognize two seasons - summer and winter. You could put the boundary at equ…
Re: Why we’re switching to calendar versioning
#90Just so you know, season based names make no sense since the Southern Hemisphere exists. Also there’s no such thing as Fall in a lot of places.
I don't care to research the country of the developer and then the dates that are considered summer in that country just because they were so ignorant they used a season as a timeframe.