3 ms·

The benefits are actually much deeper though. Now that we know exactly how the API has changed, it is possible to automatically enforce strict versioning rules.

The benefits are actually much deeper though. Now that we know exactly how the API has changed, it is possible to automatically enforce strict versioning rules. If there are breaking changes, the new release must be a major version bump. This is very interesting to me. It demands consideration: do we need a person to manually bump the version anymore at all? If you can statically verify that a change meets the criteria, couldn't the package publishing process autoincrement the appropriate version segment and be done with it?

riffraff 12y ago
there are probably cases in which you want to change the version independently of API changes, i.e. "going stable" (0.x to 1.0), major internal changes, new interfaces with deprecations of the old ones etc.
- couchand 12y ago
  Good point, you still need an escape hatch to bump a version segment higher than the minimum necessary one, for many reasons. I'm not sure I agree that the phrase "going stable" really applies to a semver project. The most stable release would just be the highest number in each segment. Version 1.0.1 is almost by definition going to be more stable than 1.0.0, since the changes are only backwards-compatible bug fixes. At least that's my understanding of semver.
  - riffraff 12y ago
    semver has a special case for 0.x, which is basically "before 1.0 there are no guarantees". In their words: > Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. (Yes, this means that you can use 0.x and declare yourself "semver compatible" and break on any patch release)
zimbatm 12y ago
It seems doable to differentiate additions from (breaking) changes if all the API is statically defined. It would be nice to even have the feedback on larger changes. That being said it's possible to change a library's behaviour without touching the API. Consider the following diff: -add a b = a + b +add a b = a - b Granted the example is simplistic. With the API versioning system in place the author should have renamed the method and would have gotten the right result. It's just to show that it wouldn't be a silver bullet.
- couchand 12y ago
  My attitude towards developer tooling tends to be: build the tools first for the experts, and second make sure the are learnable. I can't stand professional tools that are built primarily for new users. Englebart's violin [0] and all that. That said, it might be the case that removing the responsibility of versioning from experts would make them less concerned about the ramifications, and less likely to notice when they make a change like this one (well not this one exactly, but one similar but more reasonable). You really do need tests in addition to static analysis to be sure of these things. [0]: http://www.loper-os.org/?p=861 http://www.loper-os.org/?p=861
  - jmite 12y ago
    I think it has as much to do with standardization as ease of use. This way, if there are multiple experts, they don't each do it their own way. Plus, it gives a degree of reliability to those using the packages, which is something you can't necessarily count on in Haskell right now.

riffraff 12y ago

there are probably cases in which you want to change the version independently of API changes, i.e. "going stable" (0.x to 1.0), major internal changes, new interfaces with deprecations of the old ones etc.

couchand 12y ago
Good point, you still need an escape hatch to bump a version segment higher than the minimum necessary one, for many reasons. I'm not sure I agree that the phrase "going stable" really applies to a semver project. The most stable release would just be the highest number in each segment. Version 1.0.1 is almost by definition going to be more stable than 1.0.0, since the changes are only backwards-compatible bug fixes. At least that's my understanding of semver.
- riffraff 12y ago
  semver has a special case for 0.x, which is basically "before 1.0 there are no guarantees". In their words: > Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. (Yes, this means that you can use 0.x and declare yourself "semver compatible" and break on any patch release)

zimbatm 12y ago

It seems doable to differentiate additions from (breaking) changes if all the API is statically defined. It would be nice to even have the feedback on larger changes. That being said it's possible to change a library's behaviour without touching the API. Consider the following diff: -add a b = a + b +add a b = a - b Granted the example is simplistic. With the API versioning system in place the author should have renamed the method and would have gotten the right result. It's just to show that it wouldn't be a silver bullet.

couchand 12y ago
My attitude towards developer tooling tends to be: build the tools first for the experts, and second make sure the are learnable. I can't stand professional tools that are built primarily for new users. Englebart's violin [0] and all that. That said, it might be the case that removing the responsibility of versioning from experts would make them less concerned about the ramifications, and less likely to notice when they make a change like this one (well not this one exactly, but one similar but more reasonable). You really do need tests in addition to static analysis to be sure of these things. [0]: http://www.loper-os.org/?p=861 http://www.loper-os.org/?p=861
- jmite 12y ago
  I think it has as much to do with standardization as ease of use. This way, if there are multiple experts, they don't each do it their own way. Plus, it gives a degree of reliability to those using the packages, which is something you can't necessarily count on in Haskell right now.