3 ms·

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 c

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 5y 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.
- travisjungroth 5y 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.
  - didibus 5y ago
    Actually Python pretty much did what I describe, and on a lot of OS you will have a python2 and a python3 executable coexisting. I think you're conflating name and version. Your new name can be: name2 if you want, but your version string can reset to 1.0 So if I had a lib called Birdy, and I was doing FEATURES.BUGS maybe I'm now at Birdy v3.45 Now say I want to make a breaking change I can release Birdy2 v1.0
    - travisjungroth 5y ago
      I think you're conflating name and executable. There's not a Python2 Software Foundation and a Python3 Software Foundation. When I run python I get back 3.9.6, not 9.6. My point is that people advocating for "never break stuff, make new things with a new name" are wrong when they act like that's superior to semantic versioning because those two options are isomorphic. You can translate Birdy 1.3.45 to Birdy1 3.45 and Birdy 2.1.0 to Birdy2 1.0. You can even translate it in your code with aliasing. And if this somehow a way better system, there should be some big benefit, right? But there isn't. People want their software to not break, and they want to know when it does. Some people accept that software is going to break all the time and they're like "Please just tell me about it by bumping major version. High major versions = honest." And then other people don't accept it will break and are like "Please don't break my stuff. High major versions = unreliable.". Where I think the "don't break my stuff" crowd goes astray is when they act like it has anything to do with naming. They'd be just as annoyed if I released 17 different software packages named after bird species, and all but the most recent are not supported. The problem is the 17, now how it's expressed.
- paulddraper 5y ago
  Yeah, but what Chrome/Firefox version are you using?

lolinder 5y 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.

travisjungroth 5y 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.
- didibus 5y ago
  Actually Python pretty much did what I describe, and on a lot of OS you will have a python2 and a python3 executable coexisting. I think you're conflating name and version. Your new name can be: name2 if you want, but your version string can reset to 1.0 So if I had a lib called Birdy, and I was doing FEATURES.BUGS maybe I'm now at Birdy v3.45 Now say I want to make a breaking change I can release Birdy2 v1.0
  - travisjungroth 5y ago
    I think you're conflating name and executable. There's not a Python2 Software Foundation and a Python3 Software Foundation. When I run python I get back 3.9.6, not 9.6. My point is that people advocating for "never break stuff, make new things with a new name" are wrong when they act like that's superior to semantic versioning because those two options are isomorphic. You can translate Birdy 1.3.45 to Birdy1 3.45 and Birdy 2.1.0 to Birdy2 1.0. You can even translate it in your code with aliasing. And if this somehow a way better system, there should be some big benefit, right? But there isn't. People want their software to not break, and they want to know when it does. Some people accept that software is going to break all the time and they're like "Please just tell me about it by bumping major version. High major versions = honest." And then other people don't accept it will break and are like "Please don't break my stuff. High major versions = unreliable.". Where I think the "don't break my stuff" crowd goes astray is when they act like it has anything to do with naming. They'd be just as annoyed if I released 17 different software packages named after bird species, and all but the most recent are not supported. The problem is the 17, now how it's expressed.
paulddraper 5y ago
Yeah, but what Chrome/Firefox version are you using?