21–30 of 167 posts
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."
> 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.
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.
"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.
The entire spec is like a 10 minute read. Anyone using semver should have at least read the semver spec. Anyway, the bullet on tagging:
“Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.”
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…
I never found stric following of semantic versioning to be a good fit for product versions. It makes sense only for libraries and packages.
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.
You hear about about WPA3 being broken in April 2019. It's obvious your WPA3 18.10 lib is vulnerable, WPA3 19.04 is not.
It's a lot simpler to parse and can lead to less mistakes.
Earlier quoted context omitted.
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 c…
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?