4 ms·

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,

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.

didibus 5y ago
I'm talking from the point of view of dependency management and code linking, for which it makes a big difference. This isn't about the natural language interpretation. You cannot link against two things that have the same name, that's the point of changing the name. And if you keep the version string as a mechanism to show non-breaking changes, you can safely bump it up. Python packagers mostly followed the advice I mentioned, and they packaged Python 2 and 3 using different package and executable names. If they had used the same name, a bunch of things would have been broken. Imagine a script that is broken by Python 3 which does: #!/usr/bin/env python So when the 2 to 3 migration happened package managers did this: python2 python3 python -> python2 And if you are writing a script that needs Python 3 features you'd do: #!/usr/bin/env python3 Had they not decided to change the name, a lot of things would have been broken. Now the more common case are going to be direct code dependencies for an app. You have a lib called foo, and I depend on it for my application: "dependencies": { "foo": "1.5.8", "bar": "1.3.7" } Now you make breaking changes, you could do: "dependencies": { "foo": "2.0.0", "bar": "1.3.7" } But this forces me to upgrade all at ounce. For example, if bar dependency is also broken by foo 2.0.0, I first have to wait for them to upgrade, etc. If you had released foo2 I could choose to upgrade whenever I want, before bar does, after bar does, or even start by upgrading only half my code to foo2 while the other half is still on foo. "dependencies": { "foo2": "1.0", "bar": "1.3.7" } The downsides of this I've heard is that it might mean less people end up migrating to the new thing, and that it can end up growing the number of dependencies pulled in, since you would pull foo2 and bar and bar would pull foo, for a total of 3. Where-as otherwise you'd wait for bar to use foo2 and then you'd pull foo2 and bar, for a total of 2. And some people say it's good to have this downward pressure to force others to also upgrade to keep everyone aligned on latest versions, might be good for security, or just to keep the pace of progress high. There's also another strategy which is more granular, which is to version the actual code modules or even functions: So maybe your breaking change doesn't break everything but it does break your date module: module foo.v1.date becomes: module foo.v2.date And the dependency is just a feature bump: "foo": "1.1.0" Now your users can choose the V2 module if they prefer it's APIs and features or stay on V1. That one might be harder for the author to maintain over time though. And even more granular is at the function level: function foo-cool() {...} function foo-cool-v2 {...}

didibus 5y ago

I'm talking from the point of view of dependency management and code linking, for which it makes a big difference. This isn't about the natural language interpretation. You cannot link against two things that have the same name, that's the point of changing the name. And if you keep the version string as a mechanism to show non-breaking changes, you can safely bump it up. Python packagers mostly followed the advice I mentioned, and they packaged Python 2 and 3 using different package and executable names. If they had used the same name, a bunch of things would have been broken. Imagine a script that is broken by Python 3 which does: #!/usr/bin/env python So when the 2 to 3 migration happened package managers did this: python2 python3 python -> python2 And if you are writing a script that needs Python 3 features you'd do: #!/usr/bin/env python3 Had they not decided to change the name, a lot of things would have been broken. Now the more common case are going to be direct code dependencies for an app. You have a lib called foo, and I depend on it for my application: "dependencies": { "foo": "1.5.8", "bar": "1.3.7" } Now you make breaking changes, you could do: "dependencies": { "foo": "2.0.0", "bar": "1.3.7" } But this forces me to upgrade all at ounce. For example, if bar dependency is also broken by foo 2.0.0, I first have to wait for them to upgrade, etc. If you had released foo2 I could choose to upgrade whenever I want, before bar does, after bar does, or even start by upgrading only half my code to foo2 while the other half is still on foo. "dependencies": { "foo2": "1.0", "bar": "1.3.7" } The downsides of this I've heard is that it might mean less people end up migrating to the new thing, and that it can end up growing the number of dependencies pulled in, since you would pull foo2 and bar and bar would pull foo, for a total of 3. Where-as otherwise you'd wait for bar to use foo2 and then you'd pull foo2 and bar, for a total of 2. And some people say it's good to have this downward pressure to force others to also upgrade to keep everyone aligned on latest versions, might be good for security, or just to keep the pace of progress high. There's also another strategy which is more granular, which is to version the actual code modules or even functions: So maybe your breaking change doesn't break everything but it does break your date module: module foo.v1.date becomes: module foo.v2.date And the dependency is just a feature bump: "foo": "1.1.0" Now your users can choose the V2 module if they prefer it's APIs and features or stay on V1. That one might be harder for the author to maintain over time though. And even more granular is at the function level: function foo-cool() {...} function foo-cool-v2 {...}