Semver doesn't mean major.minor.patch, it means fails.features.bugs

https://twitter.com/willmcgugan/status/1423678688802058244

by Tomte • 5 years ago

275 166 5 years ago

twitter.com

tedajax2• 5 years ago

What an abysmal mindset.

chomp• 5 years ago

Can you explain why you don’t like this?

3np6• 5 years ago

How so? It's precisely as intended. Here's thesemver summary:

Given a version number MAJOR.MINOR.PATCH, increment the:

    MAJOR version when you make incompatible API changes,
    MINOR version when you add functionality in a backwards compatible manner, and
    PATCH version when you make backwards compatible bug fixes.

https://semver.org/

one_off_comment4• 5 years ago

I'm not tedajax, but my guess as to what they meant is that it's an abysmal mindset to think that making a breaking change to an API means that the previous API was wrong. And I tend to agree. Needs and assumptions change and sometimes that means your API needs to adapt in a backwards-incompatible way. That doesn't mean your previous API was wrong for what it was built for. It just means it's wrong for the new expectations.

I agree with tedajax that looking at any breaking changes as a failure is a pessimistic, fatalistic, harmful viewpoint... assuming that's what tedajax had in mind.

andrew_5• 5 years ago

they're a permanent reminder of how many times you got the API wrong

I'd agree in part with this sentiment only for the last segment: PATCH. Otherwise, unless you're just producing a mountain of garbage on a routine basis, they're more an indicator of _improvements_ in an API or a versioned thing.

As it goes with Twitter, the tweet author didn't provide nearly enough nuance to justify the statement.

one_off_comment4• 5 years ago

You're correct. As usual, the truth lies somewhere in between the two extremes.

People seem to really hate the gray area despite the fact the most of life lies in it.

BoorishBears5• 5 years ago

They don't hate the gray area, they pretend to hate the gray area because the gray area doesn't get you on the front page of HN

simonw19• 5 years ago

Surely the minor version number (FEATURE) in this model is the indicator of improvements to the versioned thing?

rolha-capoeira• 5 years ago

"How many times you got the API wrong"? I get the concept, and maybe it's correct some of the time... but it ignores the vast majority of software releases over time, which are evolved products/projects. What I initially set out to do != what's valuable/useful to the world.

simonw19• 5 years ago

So you got the API wrong - because you didn't have omniscience about every possible problem your code would need to solve in the future.

There's no shame in admitting that with a major version bump. None of us are infallible.

rgoulter• 5 years ago

This makes me wonder what the largest MAJOR in MAJOR.MINOR.PATCH exists in the wild.

qzw• 5 years ago

So Chrome has had 92 fails and around 70% of the browser market. Guess I’m not failing enough then.

[edit] Yes, I missed the semver part of the tweet. This is why I’m not on twitter, and should stay out of these threads in the future.

simonw19• 5 years ago

Chrome doesn't use SemVer.

tobyjsullivan• 5 years ago

Maybe not technically semver but it seems close enough for the joke to hold.

https://www.chromium.org/developers/version-numbers

3np6• 5 years ago

To anyone who think they disagree: The tweet is not really an opinion or a hot take, just a rephrasing of the semantics (you know, the sem in semver). Read “Fails” as verb and not plural noun and it makes sense.

  Given a version number MAJOR.MINOR.PATCH, increment the:

    MAJOR version when you make incompatible API changes,
    MINOR version when you add functionality in a backwards compatible manner, and
    PATCH version when you make backwards compatible bug fixes.

https://semver.org/

The idea is that users can get expectations right when assessing an upgrade and plan accordingly. If you don't follow this, you're not doing semver.

dancemethis• 5 years ago

Nah, it means "boring", "yawn" and "soulless".

AnIdiotOnTheNet• 5 years ago

If more developers had had this mindset, DLL hell might not have ever been a thing.

shadowgovt2• 5 years ago

Oh, you can definitely get into DLL hell with semantically versioned APIs. DLL hell is mostly a symptom of diamond dependency problems... One library cares deeply about the version of a dependency, a second library cares deeply about a different version of the same dependency, and your code requires both of those libraries.

simonw19• 5 years ago

I absolutely love this (I was part of this Twitter conversation).

My take on SemVer is that the ideal version number would be something like 1.452 - 452 new feature release without ever breaking backwards compatibility.

Almost impossible to actually achieve this, but it's good to be ambitious!

Also: doing SemVer properly requires you to provide really good documentation. A bug fix should correct an issue where actual behavior differs from the documented behavior.

Without this, a "bug fix" is indistinguishable from a breaking change.

neolog6• 5 years ago

Why break the existing library instead of making a new one? Concretely, why not do like jinja2 and psycopg2?

simonw19• 5 years ago

Because then you have to actively maintain two libraries forever instead of one.

one_off_comment4• 5 years ago

What's the difference? It's not like the old version of the library ceases to exist. What's the difference between jinja 2.0 and jinja2 1.0?

shadowgovt2• 5 years ago

In one sense, you could. That's just taking the semantically significant information and moving it from the major revision number to the name.

But then most systems are going to consider those libraries to be entirely separate, most search engines are going to make it hard to find out about one if you find out about the other, and so on and so forth. Major version number also implies that if you have no reason to choose one over the other, you should be choosing the most recent one.

ajmurmann4• 5 years ago

Any reasonable dependency management tool should allow you to pin down any part of the semver version. For example on regular upgrade only pull patches or minors and require a manual change to upgrade otherwise. Appending a version number to the library name is a heck around completely inadequate dependency management tools. A language not having a tool en par with bundler, cargo or yarn is a massive negative for me when looking at new languages.

crdrost• 5 years ago

“So I spent a week doing OAuth2 stuff. It took a couple days to read through [Google’s] ten-thousand lines of code, so then I went and looked for other libraries. There's `python-oauth2`... it's the second version of python-oauth, it doesn't actually do OAuth2. But that took a while to figure out. So that one was a little bit better, 540 source lines of code, 15 classes, but I wasn’t going to put that in either because it didn’t actually do what I needed to do. So I rewrote that to just do bearer-token authentication, it’s ‘python-foauth,’ or if you prefer, ‘eff oauth.’”

-- Jack Diederich, “Stop Writing Classes”, https://youtube.com/watch?v=o9pEzgHorH0

treesprite82• 5 years ago

No existing project should break unless its developers take the action to upgrade (bumping the version of the library that the library manager is looking for).

The reason I'd personally prefer package 2.0.0 rather than package2 1.0.0 is because a lot of tools understand the former. For example tools can let the user know a breaking update is available, or allow me to specify that my project works with many major releases of package, or upgrade/downgrade more conveniently.

OJFord2• 5 years ago

Because that's really annoying? Boto is (forever now, presumably) v2.x, and Boto3 is on v1.x.

How is that helpful?

madeofpalk• 5 years ago

without ever breaking backwards compatibility.

Without ever intentionally breaking backwards compatibility.

OJFord2• 5 years ago

Or rather 'knowingly'. If you didn't intend it, but you find out (e.g. user reports it), you should still bump major. If you consider yourself to actually be 'doing semver' that is. And even yank the minor breaking release I suppose.

treesknees• 5 years ago

At my previous employer, we ended up handing over our versioning to the marketing/business teams and our development teams started using a semver-style internally recognized release number for tracking features and fixes. Too often our customers would demand a new feature/driver/interface in a .PATCH or .MINOR release in order to more quickly adopt the software without having to run through their internal qualifications and upgrade policies.

happytoexplain• 5 years ago

Yup. We use code names for products internally for the same reason. Never use a user-facing value as an identifier, as obnoxious as trying to adhere to that can be.

crazygringo• 5 years ago

they're a permanent reminder of how many times you got the API wrong.

I mean, that's clever for a tweet, but I hope nobody takes that seriously.

It's pretty counterproductive to view design through the lens of getting something wrong or right. There's just iteration in the direction of improvement. It didn't start out wrong -- it was your best first attempt with what you knew at the time. Then you learned more and so it improved. But it'll never be "right", just incrementally "more useful".

API's aren't mathematical proofs.

Just in case anyone needs to hear it ;)

simonw19• 5 years ago

I wonder if people would be less offended by this if it was "MISTAKES.FEATURES.BUGS".

In American culture (in my experience) everyone takes pride in learning from their mistakes - but no-one likes to think of them as failures.

jayd16• 5 years ago

PAST-MISTAKES.FUTURE-MISTAKES.CURRENT-MISTAKES

andrew_5• 5 years ago

I'm not offended. I just think it's wrong to paint with such a wide brush. Breaking changes don't always mean that something was a mistake. They often mean a change in direction, and that can happen for a myriad of reasons.

We like more nuance on HN than Twitter seems to.

3np6• 5 years ago

As I mentioned below, “fail” is an overloaded word and in server another meaning is intended. Longer but more correct: “BREAKING_CHANGES.FEATURES.BUG_FIXES”

You can get everything right and still intentionally introduce a breaking change in a future release.

secondcoming• 5 years ago

Maybe the 'offence' is from somebody reading far too much into something?

simonw19• 5 years ago

Will is now suggesting "LEARNING_OPPORTUNITIES.FEATURES.BUGS"

stonemetal12• 5 years ago

Opengl jumped from 2 to 3 because hardware changed. It doesn't mean the old API failed or was a mistake, it did the job it was intended to do, and then they needed it to do something radically different.

Lendal• 5 years ago

True. Many people get offended when you say the glass is half empty, but nobody gets offended when you say the glass is half full. If I must point out a failure, I will make sure to wink and smile while doing it, which is tough on Twitter.

Macha2• 5 years ago

Is something that can be improved inherently a mistake?

Mistake/Failure both imply an extra level of judgement "Oh, if only you'd worked harder you would have had the right API design the first time and you'd never need a new version".

Sometimes the world changes around an API.

Sometimes there is data that can only be gathered from real world usage.

Sometimes there's new use cases to handle.

inanutshellus2• 5 years ago

If one is desperate for a "fails/mistakes" kind of verb then "BREAKS" (as in "includes breaking changes") might actually hold sway, but then you'd leave out the "major functionality added" scenario for, well, MAJOR.

In short, I think OP's observation is that of a pessimist's.

If not "MAJOR.MINOR.BUG" (which needs no improvement IMO) I'd go with...

TECTONIC.FEATURE.FIX.

cratermoon• 5 years ago

My first thought was along the same lines. Especially for the major version, there's no need to imply there was a failure. Version 1.0 was the right thing at the time. Version 2.0 means something about the requirements or use cases changed in the intervening time, so it's necessary to track that change. Minor and Patch have the same implications, although in my mind a "patch" can also happen when there's just the sort of mistake the can creep in because of human imperfections.

In any case, it doesn't matter except to consumers of the API who need to know the level of backward compatibility.

kall2• 5 years ago

Seeing a project on a pretty high major is a positive signal to me. It tells me that they understand semver and know how to use breaking changes. Of course if a project is just very stable and sticks to 1.x, that‘s great too. I don‘t consider that a negative signal. Purely anecdotally, 3 is the scariest version number to me.

React sets a pretty good example here: react 17 is the most boring release in the world. The react team are not bad API designers that made 17 major mistakes. They may be the most considerate and pleasant API designers in all of frontend, actually.

React Native is on 0.64.4 (?) not because it‘s unfit for production but because they know the level of guarantees they can make about version upgrades is zero.

bpodgursky• 5 years ago

I've also seen projects on like 124.0.0 just because they don't care about semver and just release major versions every time.

dexterhaslem• 5 years ago

yes but didn't react do a big jump? like 0.13 -> 14.0 or such many moons ago. at any rate agree with the point

kstenerud• 5 years ago

Unfortunately, go has broken semver, so all of my go projects now stay at 1.x.y, with x being the "major" version (breaking changes) and y being the "minor" version (non-breaking changes) and the 1 sitting there useless. I suspect that many others do the same, so for go projects the x version field is the one to pay attention to.

Although TBH it's not all bad; all anybody has ever really cared about is "are there breaking changes or not?"

devin• 5 years ago

To me it's a signal that if I rely on this software in my own projects, I am signing up for an upgrade treadmill.

travisjungroth3• 5 years ago

2 seems to be the final number for business stuff. CustomerReportv2 or UserModel2 or /api/v2/ are wildly more common than 3 IME.

matttrotter2• 5 years ago

Amen. Although, if you're on version 931.59.12, then maybe something is wrong.

jdauriemma• 5 years ago

Almost an IP address

dragonwriter• 5 years ago

Semver doesn't mean MAJOR.MINOR.PATCH, it means FAILS.FEATURES.BUGS

It think I understand all the projects afraid to go to 1.0:

“0 fails”!

BenjiWiebe• 5 years ago

My projects stay at 0.x because they never quit failing...

0des2• 5 years ago

I disagree with the author. However, I don't think this was meant to be taken literally, but more as a tongue in cheek observation of the poster's perception of their own situation.

As an aside, recently, I've started doing YYYY-MM-DD for releases. I don't know why, but that's how I ended up subconsciously, after using semver for years. Currently, I version the API, and date the release. I have not yet had the audacity to pull this off in any larger projects, but small tools, internal releases, who's going to judge for trying something new where the risk is low?

I'm not saying it's right, just that it works for me.

jka• 5 years ago

In an imaginary world that is not very much like our current world of software development, there are no version numbers at all - only commit references.

You generally want to upgrade to the latest high-quality commit reference available, by following an upgrade path from the commit your application is currently deployed from.

Breaking changes can be identified automatically using static analysis of the commits thanks to language-level support and/or well-defined interface definitions.

For all of the important workflows you use, you have external integration tests, so you can navigate the commit-space (and potentially even merge multiple paths) fairly arbitrarily with some degree of both statistical (test coverage, performance) and qualitative (feature support, hardware compatibility) confidence.

mjw10073• 5 years ago

Using semver is a promise that if you make a backwards-incompatible change you will update the major version.

That's entirely separate from any promise, or statement of intent, that you might want to make about whether you're hoping to make backwards-incompatible changes rarely or frequently.

Teaching people that they should consider incrementing the major version as indicating a failure isn't going to be helpful.

In practice, given the way semver is defined, if this idea catches on I fear the main effect will be to increase the number of projects that never choose to declare they're version 1.0.

mjw10073• 5 years ago

More concretely, scrolling up I see that the tweeter says their threshold for declaring 1.0 is when they « feel that the API will only need to be extended in a backwards compatible way. When taking care not to break people's code is not a burden. »

I don't think that's the general understanding we should be aiming for.

Rather I think a better threshold (and the one implicit in semver's definition) is to declare 1.0 when the API is stable enough that you're willing to go to the effort of tracking whether the changes you're making are backwards-compatible.

Otherwise we're discarding useful information in the meantime.

simonw19• 5 years ago

So in your model 1.0 is the point at which you start writing proper release notes?

I'm not keen on that. During my 0.x period I still want interested third parties to try out and use my code, which means I need to give them good release information to help them help me test everything out.

ajmurmann4• 5 years ago

I find this framing to be too inward looking. SemVer isn't for me as the library developer, it's for users of my library. What it really means in that context for most users/customers outside of toy projects is:

EXPENSIVE-HIGH-RISK-UPGRADE. MEDIUM-RISK.LOW-RISK

There is a carrot-side to this but that usually only matters in specific cases for a subset of users.

EDIT: one small practical addition: If you are fixing a big that requires very large changes to how things work at a more fundamental level, I'd at least think twice about shipping that in a patch. While it technically fits the definition of SemVer, it might violate implicit expectations of users who are using your library in production. The change really needs to carry its weight.

andrew_5• 5 years ago

I like the thought process here.

In theory MINOR and PATCH are both supposed to be low risk. The risk only increases if the developer/process in control of the versioning doesn't recognize when a fix or feature contains a breaking change.

mrits• 5 years ago

MARKETING.PM.ENG is closer to my experience

ithkuil• 5 years ago

Somebody should come up with a name for this and craft a manifesto on a website :-)

Realver.org? Enterprisever? Corpver?

pcthrowaway• 5 years ago

Please add this to the Twitter thread. I'm dying laughing at how true this is

thrashh• 5 years ago

This is how I handle my libraries too. My standard is that you will never have a breaking change in any of my minor or patch versions.

I may ship new API in minor versions, and if I need to do an API rewrite, there will be a few years where you can use both APIs, then in a future major version, I will deprecate the old API (emit warnings), then in yet another future major version, I will finally remove the old API.

Basically my expectation is that if you use my library, you’re set. You’ll get new features with minimal stress.

cogman102• 5 years ago

At this point, I feel like the version numbering of semi-ver has lost all meaning.

I've been broken by every level of version bump. I've seen APIs that went from 1.0 -> 2.0 and really were only backwards incompatible because of a single method change.

I've seen countless major changes to method signatures from a 1.0 -> 1.1 bump.

I've even seen breaking API changes from a 1.0.0 -> 1.0.1 bump.

It seems like everyone has a different feeling on when those numbers should be rolled. That inconsistency makes it impossible really understand what an upgrade is going to do without tests.

kbenson3• 5 years ago

Not every project follows semver. Just because there are numbers with periods interspersed doesn't mean it's semantic versioning. People have been throwing numbers together to communicate something about what it is for a long time now, long before semantic versioning was formalized.

kodah2• 5 years ago

I think some of this is because even package maintainers have a hard time deciphering what is potentially "breaking". There was a great talk at GopherCon about an ambitious project whose goal was to be able to detect if you made backwards incompatible changes, which on the facade seems easy (to some folks, apparently) but is in fact not.

paulddraper2• 5 years ago

Because in reality every change is breaking to someone. Some just break more stuff than others.

No software story is more classic than the bugfix breakage. There is a reason versions are pinned. There is a reason lockfiles exist.

---

Whatever your intentions, versioning is HIGH.MEDIUM.LOW breakage.

I don't degenerate versioning at all; I find it to be very helpful. But don't pretend it guarantees something that it can't.

Versioning is simply a best-effort communication of risk.

simonw19• 5 years ago

I see the middle number as "RISK-FREE-UPGRADE" - if I bump that number in one of my packages it means there's a new feature, which should have no impact at all on existing code.

marcosdumay• 5 years ago

That's because you are a library author, and because you are following the standard.

A library user can't afford to assume any change is risk-free. Even when the author claims it is.

eurasiantiger3• 5 years ago

More like NEED-REFACTOR.CHECK-TODOS.CHECK-FIXMES

neilv2• 5 years ago

The PLaneT network package manager did it even simpler: APIBREAKING.NONAPIBREAKING. Which might be interpreted as NEEDSENGINEERINGLOOKBEFOREUPGRADE.SAFEAUTOUPGRADE.

This was used for PLT Scheme, and was a rather nice 90%+ very lightweight solution.

If you were doing a package where backward-compatibility was a very high priority, you might be at PLaneT version 1.x forever.

If you were doing rapidly evolving research, and wanting to share code, while not surprise-breaking people who might use your stuff, you could end up with a large major version. For example, a package by Dave Herman (of Mozilla and Rust fame) got up to 9.x in only 2 years. http://planet.racket-lang.org/display.ss?package=javascript....

I don't recall whether anyone ever encountered unexpected breaking changes in practice that the version number didn't indicate. I'd guess probably. It wasn't a 100% solution alone.

PLaneT also supported specifying in a code file import which versions of the package you were known to work with (like meaning "major version 4, with minor version 2 or later; or major version 5"), with automatic installation of those.

You could also mix multiple versions of a package in a system, in the normal case (though maybe not if you had something like singleton state or resource that multiple versions of the package wanted to control). This seemed very valuable for pulling in lots of small open source dependencies, directly and indirectly, from different developers.

One downside of this simple approach is that it's bad as a "marketing version number". Like if you wanted to convey the value of large new features (or maybe talk about them in an easy way, like "version 4 foo features"), but you've been sticking to version 1.x backward compatibility the whole time. So there was a separate marketing version number, which seemed confusing enough that there must be a better way. But it was at least 90% there.

ajmurmann4• 5 years ago

I think the difference between minors that include non-stop breaking features and patches actually is important. If you run a mission-critical system you want to minimize risk as much as possible but also get your needed fixes, especially if they are for CVEs. If it was a fair assumption that we only ever break things on purpose the PLaneT versions would be totally sufficient though.

pipework• 5 years ago

0. Time since last Intentional-Breakage/Funding-round.

1. "Features" released since last Intentional-Breakage.

2. Acknowledged mistakes since last "feature" release.

3. Scuff-ups since last mistake or "feature".

4. Comical 'release name' to distract management from size of last two numbers.

0.1.2-3-haffagudtay

0xbadcafebee2• 5 years ago

This is literally the only tweet I've ever seen posted to HN that was worth upvoting. It's not an entire book spread over 200 posts, it's just one nugget of useful info

profmonocle• 5 years ago

In the Node.js ecosystem, major semver bumps often just mean that support for an EOL version of Node was dropped. Which is a good thing IMO - allows the devs to use modern JS conventions without as much transpiling overhead.

willm• 5 years ago

Tweet author here. Please don’t @ me. I was only half serious.

The context was re Python libraries. I increase the major version when I revise the API, even if it’s single method. To my mind, that is a failure on my part to come up with the perfect API on the first pass. Of course it’s going to happen and I don’t lose sleep over it.

I’m not dissing any project that doesn’t start with a 1.!

kirse• 5 years ago

If an API is like a painting, then a changing landscape could be one reason you can paint it accurately each time but still need to make later revisions. "All models are wrong but some are useful" applies here as well. Most of SW iteration is about adjusting the painting/model to match present realities.

Either way the tweet cracks me up because it's just a matter of perspective that is giving some folks a good rankle.

j1elo• 5 years ago

People are just reacting strongly to a word that I guess in their culture has too many negative connotations. Your idea was pretty much on point and made for a fun tweet, and I think it's good enough without needing to split hairs between the slightly different possible interpretations of the word, as some are doing.

didibus3• 5 years ago

BREAKING.FEATURES.BUGS

I think would be better. And when you look at it that way, BREAKING could be in order to provide new features that necissated breaking changes, or it could be because the old way sucked and nobody liked it, or any other reason, but the version bump communicates that the changes are breaking backwards compatibility in some known way.

As an aside, this is why some people say SemVer is bad, because ideally a dependency should never be breaking you.

An alternative to SemVer is to do:

FEATURES.BUGS and simply never push breaking changes.

So what if you want to make some changes that mandates breaking compatibility?

Well you simply release a new library or framework under a new name.

That way the name of a dependency is a 1:1 correspondence with its exact interface. If the interface changes in breaking ways it's a new dependency.

This also allows you to then depend on both, possibly even letting you transition from one to the other in phases.

lolinder• 5 years ago

So what if you want to make some changes that mandates breaking compatibility?
Well you simply release a new library or framework under a new name.

I don't think that's necessary. If you use the model you propose (BREAKING.FEATURES.BUGS) and steer very clear of breaking changes until absolutely necessary, then "Framework 2" becomes in a very real sense a new product while still conveying continuity of development team, ideas, etc.

I think of Vue 3, Python 3, Bootstrap 5, or Fontawesome 6. No one would make the mistake of thinking they could just update the version number and be on their merry way. They're treated as "new dependencies", in effect, but re-using the name makes it still obvious that it's the same team and philosophy behind the new language/framework.

One aspect of each of the projects I list above is the continued commitment to maintenance on the old versions, with security and bugfixes and with the old documentation still being available for years after the new version is out. This allows organizations to treat the new major version as a new dependency, with all the caution that entails, without fear of having the rug yanked out from under them.

travisjungroth3• 5 years ago

After thinking about this topic too much, I've come to the same answer you have except you've said it better. (Although I disagree on people not thinking they can upgrade majors no problem. That for sure happens).

If you think every breaking change should have a new name, as the person above you does and I've heard come out of the Clojure community, then just append the major version number to the product name in your head. Otherwise, what do you expect them to name it? A name that kinda reminds people of the first one? If it's mostly the same group of people solving mostly the same problem in mostly the same way at a later point in time, NAME N -> NAME N+1 captures that better than anything else.

For all the shit we give the Python 2 to 3 upgrade (and they give themselves) I have never heard an alternative that I really find satisfying. It seems the problem was: We want to stop working for free on this old stuff we don't like any more. We want to keep the name, the websites and t-shirts since we own them and we're doing almost the same thing. Every answer I hear wants the people working for free to give up one of those reasonable things.

paulddraper2• 5 years ago

Yeah, but what Chrome/Firefox version are you using?

bryanmikaelian• 5 years ago

Reminds me of the talk Rich Hickey gave about Clojure Spec and why semver fails.

https://youtu.be/oyLBGkS5ICk

dmitriid• 5 years ago

I strongly encourage people to use ComVer instead: https://gitlab.com/staltz/comver

It's <BREAKING CHANGES>.<100% BACKWARDS COMPATIBLE CHANGES>

That's it. Fully SemVer compatible, if you want (just add .0 at the end)

JamesSwift• 5 years ago

Should I read the release notes in depth?

DEFINITELY.PROBABLY.POSSIBLY

greggyb• 5 years ago

There's a really good Rich Hickey talk about versioning. Agree or not, it's a great prompt for considering what you want from versioning.

https://www.youtube.com/watch?v=oyLBGkS5ICk

tialaramex• 5 years ago

I don't buy that the need to bump Major is a failure.

This is particularly true if you continue to maintain the previous major version to the same degree (if any) that you maintain the new one, and especially true if you have an explicit release lifetime strategy.

If I tell you that misfortunate 1.x will be actively seeing new work until 2025 and then bug fixes until 2028, and I deliver, misfortunate 2.x doesn't break that promise. Maybe you wish a new feature from misfortunate 2.6 could have been in 1.34 instead, but too bad I never promised that and most likely the way I did it would be incompatible with 1.34 anyway.

I also think that people underestimate how bad bugs can be. Sometimes the minimum fix is a breaking change.

m0llusk• 5 years ago

Posting on Twitter is a red flag indicating the author has a weak grasp of the material and nothing significant to contribute.

karmakaze• 5 years ago

If those are the axes, then it should really be fails.bugs.features since new features can be safely added but changing an existing function which had a 'bug' can be unpredictable.

nrvn• 5 years ago

This is exactly what https://www.conventionalcommits.org/en/v1.0.0/#summary advocates

And this is exactly what https://semver.org/spec/v2.0.0.html implies.

Happy coding!

Semver doesn't mean major.minor.patch, it means fails.features.bugs

Related Stories