101–110 of 167 posts
This feels like the "product version" has taken over again. I promote semver internally primarily for wiring together build automation. But I also try to make it clear that there can be a _completely different_ "product version" that can mean whatever the hell we want it to be. Calendar versions are great product versions. Many people, frequently product managers, are very uncomfortable with this distinction. So many…
Earlier quoted context omitted.
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.
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.
An 80% solution in this problem space is correctly interpreted as "there's a 20% chance an upgrade will break my business." From a risk-management perspective, at least calendared versioning implies that you'll have to do your own homework on which upgrades are incompatible, which is at least more honest than ineffective rigor.
Earlier quoted context omitted.
They also mention in the article how they don't support skipping releases, so it sounds like you have to upgrade to each point release anyway? Really if you're not constantly updating dependencies as part of your pipelines, you're going to quickly get into dependency rot issues.
I'm always surprised at how often developers freeze a set of versions and leave them for a lifetime. In my past three companies I have been the only one interested in pushing dependencies on a regular basis. I always start with a massive backlog, and end up having to incrementally update from the Stone Age to $today. Once that's set and tests pass it's easy to keep things up-to-date, you end up with single-digit chan…
https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...
> 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.
Apologies for being pedantic, but nearly 90% of the world's population lives in the Northern Hemisphere, which also holds most of the land as well. I'd say they're only 10% off
Earlier quoted context omitted.
They also mention in the article how they don't support skipping releases, so it sounds like you have to upgrade to each point release anyway? Really if you're not constantly updating dependencies as part of your pipelines, you're going to quickly get into dependency rot issues.
I'm always surprised at how often developers freeze a set of versions and leave them for a lifetime. In my past three companies I have been the only one interested in pushing dependencies on a regular basis. I always start with a massive backlog, and end up having to incrementally update from the Stone Age to $today. Once that's set and tests pass it's easy to keep things up-to-date, you end up with single-digit chan…
Too many developers think banging out code as fast as they can is "doing their job well".
This feels like the "product version" has taken over again. I promote semver internally primarily for wiring together build automation. But I also try to make it clear that there can be a _completely different_ "product version" that can mean whatever the hell we want it to be. Calendar versions are great product versions. Many people, frequently product managers, are very uncomfortable with this distinction. So many…
Semver uses the version number to convey useful information. Getting rid of semver just eliminates that information.
If you want to bump versions for marketting, that's perfectly valid. Just use a separate product version.
My SVN commit numbers and git hashes also fail to convey useful marketting information, but that's no reason to get rid of them!
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…
That sounds like an awful idea that will result in people adding version information to the name, not to mention destroying discoverability.
This feels like the "product version" has taken over again. I promote semver internally primarily for wiring together build automation. But I also try to make it clear that there can be a _completely different_ "product version" that can mean whatever the hell we want it to be. Calendar versions are great product versions. Many people, frequently product managers, are very uncomfortable with this distinction. So many…
Keep those separate or have constant missunderstandings, arguments, and frustration. Sadly, I talk from experience.