6 ms·

In my usage of SemiVer I felt it lacked what I call a "gestalt number" which would be the first number, representing broad changes to the design which (almost a

In my usage of SemiVer I felt it lacked what I call a "gestalt number" which would be the first number, representing broad changes to the design which (almost always) necessarily include API changes. But API changes can happen within the same "gestalt".

matthewaveryusa 8y ago
openssl kind of works like that -- but I believe they are moving to semver
zozbot123 8y ago
Why does a SemVer spec have to deal with that? Why not have a "gestalt" number/indicator for purely informal use, but keep the SemVer part as is?
- StavrosK 8y ago
  And call the project Foo 3 v4.1.9? That seems pretty confusing.
- dtech 8y ago
  That's essentially a 4-part version number. For most projects it's over the top and almost no-one used or uses 1.2.3.4 version numbers. I've seen libraries use "library3 1.6.2" [1] but it feels very strange and confusing. [1] https://github.com/etorreborre/specs2/releases https://github.com/etorreborre/specs2/releases
rspeer 8y ago
I've certainly encountered this issue. When I release ConceptNet, I would like to follow SemVer, but it kind of has to be in a way that the second component of the version is the major version, because there are bigger things that happen in a multi-decade project than just API changes. The project is ConceptNet 5. It is the fifth project named ConceptNet. What it has in common with ConceptNet 4 is some of the data and the spirit of the problem to be solved; the design is quite different. It's on the sixth major version after the initial release, so I call it ConceptNet 5.6. The current version is 5.6.4. If I wanted to use tools that expect SemVer, I'd have to call it something like "ConceptNet 5 v6.4". I find that confusing, and I think other people would too.
dtech 8y ago
Yes, that is my biggest problem with semver too. Will upgrading 15.1.2 to 16.0.0 be a big upgrade? It could be a single function changing it's signature or a whole different API. It also encourages version bloat. Previously a 2.8.0 upgrade to 3.0.0 meant a big change. Now you just see versions 1 through 40 with very little usage of minor version numbers. I don't know of a good way to fix it. At least semver is something everyone more or less agrees on.
- sixstringtheory 8y ago
  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.
guelo 8y ago
One option is to move the "gestalt number" into the name. It's more common in end user software than APIs since it's more of a marketing thing. Like Mac OS X, Windows 10, Sublime Text 3. It doesn't have to be a number either, like Photoshop CC.

matthewaveryusa 8y ago

openssl kind of works like that -- but I believe they are moving to semver

zozbot123 8y ago

Why does a SemVer spec have to deal with that? Why not have a "gestalt" number/indicator for purely informal use, but keep the SemVer part as is?

StavrosK 8y ago
And call the project Foo 3 v4.1.9? That seems pretty confusing.
dtech 8y ago
That's essentially a 4-part version number. For most projects it's over the top and almost no-one used or uses 1.2.3.4 version numbers. I've seen libraries use "library3 1.6.2" [1] but it feels very strange and confusing. [1] https://github.com/etorreborre/specs2/releases https://github.com/etorreborre/specs2/releases

rspeer 8y ago

I've certainly encountered this issue. When I release ConceptNet, I would like to follow SemVer, but it kind of has to be in a way that the second component of the version is the major version, because there are bigger things that happen in a multi-decade project than just API changes. The project is ConceptNet 5. It is the fifth project named ConceptNet. What it has in common with ConceptNet 4 is some of the data and the spirit of the problem to be solved; the design is quite different. It's on the sixth major version after the initial release, so I call it ConceptNet 5.6. The current version is 5.6.4. If I wanted to use tools that expect SemVer, I'd have to call it something like "ConceptNet 5 v6.4". I find that confusing, and I think other people would too.

dtech 8y ago

Yes, that is my biggest problem with semver too. Will upgrading 15.1.2 to 16.0.0 be a big upgrade? It could be a single function changing it's signature or a whole different API. It also encourages version bloat. Previously a 2.8.0 upgrade to 3.0.0 meant a big change. Now you just see versions 1 through 40 with very little usage of minor version numbers. I don't know of a good way to fix it. At least semver is something everyone more or less agrees on.

sixstringtheory 8y ago
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.

guelo 8y ago

One option is to move the "gestalt number" into the name. It's more common in end user software than APIs since it's more of a marketing thing. Like Mac OS X, Windows 10, Sublime Text 3. It doesn't have to be a number either, like Photoshop CC.