3 ms·

I don't get the issue with large major versions. That just means that instead of holding a change for a looong time until it was "acceptable" to create a new br

I don't get the issue with large major versions. That just means that instead of holding a change for a looong time until it was "acceptable" to create a new breaking version, they released the changes asap for developers to take advantage of, and clearly communicated each time that there was something you'd need to take care of. For developers who would wait that long anyways, there's no difference between moving from 2.x.x to 40.x.x over 2 year's time than 2.x.x to 3.x.x over the same time period. (Edit to add: except that if you more regularly upgraded versions between 2.x.x and 40.x.x, you don't wind up with needing to make a huge amount of changes in one go from 2.x.x to 3.x.x.)

freehunter 8y ago
It's a big question of "am I comfortable updating" when you see a major version increase. If a project is doing a major version update every month, in my mind that's probably not a well designed project, the developers really didn't think their API through, and it's a huge risk to my business trying to integrate that into my product. Every month I'm going to have potentially breaking changes that will suck down developer time. For projects like Rails, where they optimize for developer productivity, it's good that we've only had 5 versions in 13 years. It's a stable platform to base a business from. When I see projects like React where they've released 16 major versions in 5 years, as a small developer that is a huge risk to take. There should not be that many breaking changes if the project was well thought out from the start, and I can't spend that much time fixing everything that breaks every few months. And if the project was so poorly conceived that it needs 16 major versions in 5 years, there's probably a lot of broken stuff in version 15 that I need to update to version 16 to fix, so I can't just stick with the older version. On the other hand, I feel Python waited way too long between 2.0 and 3.0 and introduced too many changes all at once, leading to the headache of so many people still using 2.x more than 10 years after the release of 3.0.
- mcaruso 8y ago
  > When I see projects like React where they've released 16 major versions in 5 years They haven't really, they just jumped from 0.14 to v15, because people were referring to 0.x releases as "version x". v15 is basically v1.x and v16 is v2.x
  - freehunter 8y ago
    But that's the benefit of semver (or romver like other people have mentioned). It takes the guesswork out of it. Also can we talk about the silly trend of publicly released software used by thousands or millions of people on production apps and they haven't made it to version 1.0 yet? 0.x is for unreleased software. If you've released it to the public, it's 1.x. As a small developer that's another huge red flag... functionally there is no difference between 0.15 and 15.0. They both indicate poorly conceived projects where the version numbers mean absolutely nothing and there's no guarantee that it will work tomorrow. And I say that as someone who uses React, I'm not just hating on it from the outside. I'm seriously terrified by the version numbers.
dtech 8y ago
The biggest problem is with an ecosystem of libraries. I avoid libraries that depend on Google's Guava because one uses 21, another 24, another 23.5. There will maybe be a year between 21 and 25. All binary incompatible. So you either need to stick to 1 version for the whole ecosystem or use tricks to give each library its own exact version of Guava it expects.
- AgentME 8y ago
  That seems like a problem with Java or Maven: it doesn't allow multiple major versions of a library to co-exist within a project. NPM and I believe Cargo both allow this. There's cases where this isn't great (where multiple libraries each need to communicate with each other using a data structure implemented by another library, but they each depend on a different version of the data structure library, or where the library you have multiple versions of is gigantic; this might be a good argument for using many small and focused libraries instead of fewer big ones), but overall allowing multiple versions in one project can save a lot of needless headaches.
  - dtech 8y ago
    The NPM approach does not have that specific downside indeed, but like you said. What are you going to do when both return a different version of a Type to the "main" code? It's not a Java/Maven problem. Rubygems, Pip and Cabal have the same restriction, and that's only the ones I know that have it.

freehunter 8y ago

It's a big question of "am I comfortable updating" when you see a major version increase. If a project is doing a major version update every month, in my mind that's probably not a well designed project, the developers really didn't think their API through, and it's a huge risk to my business trying to integrate that into my product. Every month I'm going to have potentially breaking changes that will suck down developer time. For projects like Rails, where they optimize for developer productivity, it's good that we've only had 5 versions in 13 years. It's a stable platform to base a business from. When I see projects like React where they've released 16 major versions in 5 years, as a small developer that is a huge risk to take. There should not be that many breaking changes if the project was well thought out from the start, and I can't spend that much time fixing everything that breaks every few months. And if the project was so poorly conceived that it needs 16 major versions in 5 years, there's probably a lot of broken stuff in version 15 that I need to update to version 16 to fix, so I can't just stick with the older version. On the other hand, I feel Python waited way too long between 2.0 and 3.0 and introduced too many changes all at once, leading to the headache of so many people still using 2.x more than 10 years after the release of 3.0.

mcaruso 8y ago
> When I see projects like React where they've released 16 major versions in 5 years They haven't really, they just jumped from 0.14 to v15, because people were referring to 0.x releases as "version x". v15 is basically v1.x and v16 is v2.x
- freehunter 8y ago
  But that's the benefit of semver (or romver like other people have mentioned). It takes the guesswork out of it. Also can we talk about the silly trend of publicly released software used by thousands or millions of people on production apps and they haven't made it to version 1.0 yet? 0.x is for unreleased software. If you've released it to the public, it's 1.x. As a small developer that's another huge red flag... functionally there is no difference between 0.15 and 15.0. They both indicate poorly conceived projects where the version numbers mean absolutely nothing and there's no guarantee that it will work tomorrow. And I say that as someone who uses React, I'm not just hating on it from the outside. I'm seriously terrified by the version numbers.

dtech 8y ago

The biggest problem is with an ecosystem of libraries. I avoid libraries that depend on Google's Guava because one uses 21, another 24, another 23.5. There will maybe be a year between 21 and 25. All binary incompatible. So you either need to stick to 1 version for the whole ecosystem or use tricks to give each library its own exact version of Guava it expects.

AgentME 8y ago
That seems like a problem with Java or Maven: it doesn't allow multiple major versions of a library to co-exist within a project. NPM and I believe Cargo both allow this. There's cases where this isn't great (where multiple libraries each need to communicate with each other using a data structure implemented by another library, but they each depend on a different version of the data structure library, or where the library you have multiple versions of is gigantic; this might be a good argument for using many small and focused libraries instead of fewer big ones), but overall allowing multiple versions in one project can save a lot of needless headaches.
- dtech 8y ago
  The NPM approach does not have that specific downside indeed, but like you said. What are you going to do when both return a different version of a Type to the "main" code? It's not a Java/Maven problem. Rubygems, Pip and Cabal have the same restriction, and that's only the ones I know that have it.