7 ms·

A lot of people are commenting that SemVer doesn't work, because it's still at the mercy of humans choosing good version numbers. Elm's package manager, elm-pa

A lot of people are commenting that SemVer doesn't work, because it's still at the mercy of humans choosing good version numbers. Elm's package manager, elm-package, actually tries to remove humans from the equation, by automatically choosing the next version number, based on a diff of the API and the exported types of a package: https://github.com/elm-lang/elm-package#publishing-updates https://github.com/elm-lang/elm-package#publishing-updates It's not perfect, but it's better than anything else I've seen.

unrealchild 8y ago
That’s a pretty neat strategy. Elm really brings a lot of cool (and fun) sugar to dev flows. I’ve been looking for a reason (project) to use it in so I can transition from an enamored fan-person to a true evangelist :)
User23 8y ago
Is API compatibility computable in general? My instinct is that it is, but I’ve never seen a theorem.
- ShaneWilton 8y ago
  I'd imagine it isn't, at least depending on how you define API compatibility, and whether you're only looking at the API interfaces. Imagine two versions of a library that implement the function "add". Version 1: add Int -> Int -> Int add x y = x + y Version 2: add Int -> Int -> Int add x y = x * y Both versions expose the same API interface, but the functions that conform to that interface are semantically different. A stronger type system could probably differentiate between the two functions, but I doubt you could generally compute whether both functions implement the same behavior. Perhaps with some sort of functional extensionality you'd be able to compute compatibility perfectly, but I can't imagine that ever being feasible in practice. That being said, what Elm does offer is still a huge improvement over humans trying to guess whether they made any breaking changes :)
  - toast0 8y ago
    I don't think 'does it work exactly the same' isn't necessarily the right question, given there are expected to be bug fixes which may change the behavior in some functions.
    - marcosdumay 8y ago
      The right question is "what's the difference between a bug-fix and a breaking change?"
      - Nadya 8y ago
        Irrelevant. If fixing a bug is a breaking change then it is a breaking change. This is the importance of pre-releases/"nightly" branches so that you don't have a mistake of addNumbers(5,5) returning 25 instead of 10 and not being caught and then needing to increment a major number to fix a typo of × to +. A bug fix is a change. A breaking change is a change that breaks the API. Doesn't matter if the previous status was the intended one or not. SemVer not working is almost entirely people simply not following it correctly. The projects that follow it as best as they can have very few mistakes were "woops that was a major change" occurs while projects that use it as a guideline may as well not be using it at all.
        hluska 8y ago
        Irrelevant?? That is the most relevant question that a developer could ask in this situation. Often, there are ways to work around bugs in an API. And, just as often, those workarounds will break as soon as the bug is fixed. The API developer is in a particularly poor place to judge whether a bug fix is breaking or not. Sometimes, they can talk to users to see if a change will break their code, but other times they can't. Thus, it comes down to how well a developer can predict whether a fix will break projects in the wild.
        tremon 8y ago
        Irrelevant?? That is the most relevant question that a developer could ask in this situation. No, it isn't. The most relevant question is "can somebody be using the current API". It doesn't matter if your current API matches the documentation, what matters is whether your current API is out there for others to build on. Don't try to use a crystal ball or other form of divination to predict what your downstream users have been doing with the code; you will always lose. Instead, suck it up, acknowledge the mistake, and signal the breaking change by bumping the major version. Maybe next time your developers will spend more time validating their public contract, so they won't have to endure the embarrassment of a major version bump.
- beefsack 8y ago
  Only as far as the type system supports, but I feel like constraining the minimum version unit to increment is far better than doing nothing. Disallowing incrementing the patch version when the types of existing API changes is great.
- dbaupp 8y ago
  No, it isn't computable (that is, correctly determining one of "these functions behave the same" or "these functions behave differently", and not "unknown") in general, as it is equivalent to the halting problem. Consider these two versions of a function, are they API compatible? def foo(): return True def foo(): return halts("some turing machine program") They're only truly API compatible if the program halts, but the program can be arbitrary, so proving that any 'foo' of this style are equivalent is solving the halting problem. Of course, one can still likely get useful answers of "definitely incompatible" etc., with much more tractable analyses. AIUI, the Elm version ends up just looking at the function signature, and catches things like removing or adding arguments: for appropriately restricted languages, it is likely to even be possible to determine if downstream code will still compile, but that's not a guarantee it will behave correctly.
  - gmueckl 8y ago
    I wonder if tighter guarantees can be given if tools can work with constructs like D's contracts. These are extra sections in each function that are intended to check invariants. If these invariants change, then they were either broken and needed fixing or the function had a semantic change.
    - pjmlp 8y ago
      There can still be a semantic change, even if conditions are unchanged and valid.
    - dbaupp 8y ago
      That's an interesting idea. It seems like it would be a way for tools to flag "this function is likely to have changed in an interesting way", but changing invariants doesn't necessarily mean the function breaks semver. For one, an invariant might be changed syntactically, without actually changing what it is asserting, reducing to exactly my example above: in its simplest form, the contract could go from in(true) to in(halts("...")). Secondly, an contract could have been made more permissive, e.g. in(x > 1) becoming in(x > 0), or out(y > 0) becoming out(y > 1). Assuming violating a contract is regarded as a programming error (as in, it isn't considered breaking to go from failing an assertion to not failing), these are also non-breaking changes. Lastly, changing behaviour doesn't necessarily mean changing invariants/contracts.
- jopsen 8y ago
  Type compatibility between two APIs would usually be decidable, because otherwise the type systems would be useless. But behavior testing is undecidable, easily follows from halting theorem. I doubt it would even be recognizable.
flukus 8y ago
This seems like something solved decades ago with c header files, they're easy to do a diff on and the only false negative is from adding a function. Even that would be fine if you weren't export raw structs. It seems like we gave up simple ways to do stuff like this because we hated header files and moved to tools like java and c# that eschewed them. Then they got reinvented and renamed to interfaces and we've come up with all sorts of other complicated tools (elm-package, mocking, IoC) just to recreate the functionality we lost in header files.
- LukeShu 8y ago
  Diffing C header files has way more false negatives than just "adding a function".
  - flukus 8y ago
    Such as? White space changes can be ignored, comments can be stripped pre diff, both version can be run through the same formatter before hand. What you're then left with are the actual changes. Anything removed or modified is a breaking change. Anything added to a public struct is a breaking change, which can and arguably should be hidden behind an interface. Adding functions is about all I can think of that's left. Even if it's not perfect, it's a simple 90% solution with 40 year old tools.
    - earenndil 8y ago
      What if: * Function order changes * Prototype goes from int function(char * ); to int function(char * arg); * Typedef is added so instead of int function(char* );, it's typedef char* str; int function(str);
      - flukus 8y ago
        Good points, the second one in particular I don't think could be fixed without a full parser. Function order changes could possibly be worked around by a formatter/linter that can reorder functions, at the risk of creating more issues. The last could be handled be passing the code through the preprocessor (the -E flag in gcc) first. By this point it's probably gone beyond the "perfect is the enemy of good" threshold though.
p2t2p 8y ago
I'm doing this kind of automation with Maven in Java. There is a plugin (build helper I believe is the name) that gives you properties like "next.release.version", "current.release.version", "next.snapshot.version", etc. So I've setup an infrastructure where you just click a button and it performs a release with _proper_ version number in accordance with semver, simply does the right thing. Works like a charm. I don't understand complains about human factor when you eliminate it with ease.
- oweiler 8y ago
  And who decides if a change is breaking or not?
  - kornish 8y ago
    Probably pretty simple. Destructively making a public API change is breaking. Additively changing an API isn’t. Adding an optional public param or new symbols isn’t. Harder to detect cases in which the signature stays the same but the expected behavior changes, though (as noted in TFA).
    - slavik81 8y ago
      One somewhat subtle implication is that you need to have a clearly defined expected behaviour. If people have to read your implementation to use your API, then your implementation has become the specification and basically every change will be a breaking change.
      - sacado2 8y ago
        Basically, if your old unit tests break, or if the post-conditions changed (in case you use design by contract), that's a new major version, otherwise, it's not. But yeah, there are counter-examples, and anyway a user can expect a behavior to remain even if it is not explicitely specified. For instance, I developed a SAT solver. I could make a non-breaking change that improves the efficiency of the solver in like 99.9% of the cases, because of a cool heuristic. That would be considered a "patch", since I didn't change the API at all, and all unit tests are still working perfectly. But a former user could be pissed off because he's part of the 0.1% and now the tool became just a little too slow for his use. Is that a breaking change or not?
sametmax 8y ago
I think we should stop publishing releases. Writing code is subject to human error and could break somebody else's work.
- moviuro 8y ago
  Well, if you wrote stable code in the first place, there wouldn't indeed be any need for updates!
  - sametmax 8y ago
    True. Besides, my specs are future proof. So I always offer my clients a 120 years "no update needed" guaranty, with very durable titanium punched cards.
  - eeZah7Ux 8y ago
    Jokes aside, a lot of developers would call a project "dead" when is working as intended and not receiving new commits.
    - sametmax 8y ago
      'ls' is dead, we should stop using it.
      - moviuro 8y ago
        Bad example ;) Updated on June 17th: https://github.com/coreutils/coreutils/commit/24053fbd8f9bd3639e5afd88d97d7b4bd35f61f5 https://github.com/coreutils/coreutils/commit/24053fbd8f9bd3... OpenBSD true(1) however... seems pretty much dead. https://github.com/openbsd/src/tree/master/usr.bin/true https://github.com/openbsd/src/tree/master/usr.bin/true
        sametmax 8y ago
        It's pretty amazing.
- 8y ago
pyrale 8y ago
It litterally changes nothing. I've had to fork a lib to bump a dependency version just recently. The only things that protect elm from knowing dependency hell are the age of the ecosystem and the fact that there are not that many common package publishers outside of the core team.

unrealchild 8y ago

That’s a pretty neat strategy. Elm really brings a lot of cool (and fun) sugar to dev flows. I’ve been looking for a reason (project) to use it in so I can transition from an enamored fan-person to a true evangelist :)

User23 8y ago

Is API compatibility computable in general? My instinct is that it is, but I’ve never seen a theorem.

ShaneWilton 8y ago
I'd imagine it isn't, at least depending on how you define API compatibility, and whether you're only looking at the API interfaces. Imagine two versions of a library that implement the function "add". Version 1: add Int -> Int -> Int add x y = x + y Version 2: add Int -> Int -> Int add x y = x * y Both versions expose the same API interface, but the functions that conform to that interface are semantically different. A stronger type system could probably differentiate between the two functions, but I doubt you could generally compute whether both functions implement the same behavior. Perhaps with some sort of functional extensionality you'd be able to compute compatibility perfectly, but I can't imagine that ever being feasible in practice. That being said, what Elm does offer is still a huge improvement over humans trying to guess whether they made any breaking changes :)
- toast0 8y ago
  I don't think 'does it work exactly the same' isn't necessarily the right question, given there are expected to be bug fixes which may change the behavior in some functions.
  - marcosdumay 8y ago
    The right question is "what's the difference between a bug-fix and a breaking change?"
    - Nadya 8y ago
      Irrelevant. If fixing a bug is a breaking change then it is a breaking change. This is the importance of pre-releases/"nightly" branches so that you don't have a mistake of addNumbers(5,5) returning 25 instead of 10 and not being caught and then needing to increment a major number to fix a typo of × to +. A bug fix is a change. A breaking change is a change that breaks the API. Doesn't matter if the previous status was the intended one or not. SemVer not working is almost entirely people simply not following it correctly. The projects that follow it as best as they can have very few mistakes were "woops that was a major change" occurs while projects that use it as a guideline may as well not be using it at all.
      - hluska 8y ago
        Irrelevant?? That is the most relevant question that a developer could ask in this situation. Often, there are ways to work around bugs in an API. And, just as often, those workarounds will break as soon as the bug is fixed. The API developer is in a particularly poor place to judge whether a bug fix is breaking or not. Sometimes, they can talk to users to see if a change will break their code, but other times they can't. Thus, it comes down to how well a developer can predict whether a fix will break projects in the wild.
        tremon 8y ago
        Irrelevant?? That is the most relevant question that a developer could ask in this situation. No, it isn't. The most relevant question is "can somebody be using the current API". It doesn't matter if your current API matches the documentation, what matters is whether your current API is out there for others to build on. Don't try to use a crystal ball or other form of divination to predict what your downstream users have been doing with the code; you will always lose. Instead, suck it up, acknowledge the mistake, and signal the breaking change by bumping the major version. Maybe next time your developers will spend more time validating their public contract, so they won't have to endure the embarrassment of a major version bump.
beefsack 8y ago
Only as far as the type system supports, but I feel like constraining the minimum version unit to increment is far better than doing nothing. Disallowing incrementing the patch version when the types of existing API changes is great.
dbaupp 8y ago
No, it isn't computable (that is, correctly determining one of "these functions behave the same" or "these functions behave differently", and not "unknown") in general, as it is equivalent to the halting problem. Consider these two versions of a function, are they API compatible? def foo(): return True def foo(): return halts("some turing machine program") They're only truly API compatible if the program halts, but the program can be arbitrary, so proving that any 'foo' of this style are equivalent is solving the halting problem. Of course, one can still likely get useful answers of "definitely incompatible" etc., with much more tractable analyses. AIUI, the Elm version ends up just looking at the function signature, and catches things like removing or adding arguments: for appropriately restricted languages, it is likely to even be possible to determine if downstream code will still compile, but that's not a guarantee it will behave correctly.
- gmueckl 8y ago
  I wonder if tighter guarantees can be given if tools can work with constructs like D's contracts. These are extra sections in each function that are intended to check invariants. If these invariants change, then they were either broken and needed fixing or the function had a semantic change.
  - pjmlp 8y ago
    There can still be a semantic change, even if conditions are unchanged and valid.
  - dbaupp 8y ago
    That's an interesting idea. It seems like it would be a way for tools to flag "this function is likely to have changed in an interesting way", but changing invariants doesn't necessarily mean the function breaks semver. For one, an invariant might be changed syntactically, without actually changing what it is asserting, reducing to exactly my example above: in its simplest form, the contract could go from in(true) to in(halts("...")). Secondly, an contract could have been made more permissive, e.g. in(x > 1) becoming in(x > 0), or out(y > 0) becoming out(y > 1). Assuming violating a contract is regarded as a programming error (as in, it isn't considered breaking to go from failing an assertion to not failing), these are also non-breaking changes. Lastly, changing behaviour doesn't necessarily mean changing invariants/contracts.
jopsen 8y ago
Type compatibility between two APIs would usually be decidable, because otherwise the type systems would be useless. But behavior testing is undecidable, easily follows from halting theorem. I doubt it would even be recognizable.

flukus 8y ago

This seems like something solved decades ago with c header files, they're easy to do a diff on and the only false negative is from adding a function. Even that would be fine if you weren't export raw structs. It seems like we gave up simple ways to do stuff like this because we hated header files and moved to tools like java and c# that eschewed them. Then they got reinvented and renamed to interfaces and we've come up with all sorts of other complicated tools (elm-package, mocking, IoC) just to recreate the functionality we lost in header files.

LukeShu 8y ago
Diffing C header files has way more false negatives than just "adding a function".
- flukus 8y ago
  Such as? White space changes can be ignored, comments can be stripped pre diff, both version can be run through the same formatter before hand. What you're then left with are the actual changes. Anything removed or modified is a breaking change. Anything added to a public struct is a breaking change, which can and arguably should be hidden behind an interface. Adding functions is about all I can think of that's left. Even if it's not perfect, it's a simple 90% solution with 40 year old tools.
  - earenndil 8y ago
    What if: * Function order changes * Prototype goes from int function(char * ); to int function(char * arg); * Typedef is added so instead of int function(char* );, it's typedef char* str; int function(str);
    - flukus 8y ago
      Good points, the second one in particular I don't think could be fixed without a full parser. Function order changes could possibly be worked around by a formatter/linter that can reorder functions, at the risk of creating more issues. The last could be handled be passing the code through the preprocessor (the -E flag in gcc) first. By this point it's probably gone beyond the "perfect is the enemy of good" threshold though.

p2t2p 8y ago

I'm doing this kind of automation with Maven in Java. There is a plugin (build helper I believe is the name) that gives you properties like "next.release.version", "current.release.version", "next.snapshot.version", etc. So I've setup an infrastructure where you just click a button and it performs a release with _proper_ version number in accordance with semver, simply does the right thing. Works like a charm. I don't understand complains about human factor when you eliminate it with ease.

oweiler 8y ago
And who decides if a change is breaking or not?
- kornish 8y ago
  Probably pretty simple. Destructively making a public API change is breaking. Additively changing an API isn’t. Adding an optional public param or new symbols isn’t. Harder to detect cases in which the signature stays the same but the expected behavior changes, though (as noted in TFA).
  - slavik81 8y ago
    One somewhat subtle implication is that you need to have a clearly defined expected behaviour. If people have to read your implementation to use your API, then your implementation has become the specification and basically every change will be a breaking change.
    - sacado2 8y ago
      Basically, if your old unit tests break, or if the post-conditions changed (in case you use design by contract), that's a new major version, otherwise, it's not. But yeah, there are counter-examples, and anyway a user can expect a behavior to remain even if it is not explicitely specified. For instance, I developed a SAT solver. I could make a non-breaking change that improves the efficiency of the solver in like 99.9% of the cases, because of a cool heuristic. That would be considered a "patch", since I didn't change the API at all, and all unit tests are still working perfectly. But a former user could be pissed off because he's part of the 0.1% and now the tool became just a little too slow for his use. Is that a breaking change or not?

sametmax 8y ago

I think we should stop publishing releases. Writing code is subject to human error and could break somebody else's work.

moviuro 8y ago
Well, if you wrote stable code in the first place, there wouldn't indeed be any need for updates!
- sametmax 8y ago
  True. Besides, my specs are future proof. So I always offer my clients a 120 years "no update needed" guaranty, with very durable titanium punched cards.
- eeZah7Ux 8y ago
  Jokes aside, a lot of developers would call a project "dead" when is working as intended and not receiving new commits.
  - sametmax 8y ago
    'ls' is dead, we should stop using it.
    - moviuro 8y ago
      Bad example ;) Updated on June 17th: https://github.com/coreutils/coreutils/commit/24053fbd8f9bd3639e5afd88d97d7b4bd35f61f5 https://github.com/coreutils/coreutils/commit/24053fbd8f9bd3... OpenBSD true(1) however... seems pretty much dead. https://github.com/openbsd/src/tree/master/usr.bin/true https://github.com/openbsd/src/tree/master/usr.bin/true
      - sametmax 8y ago
        It's pretty amazing.
8y ago

pyrale 8y ago

It litterally changes nothing. I've had to fork a lib to bump a dependency version just recently. The only things that protect elm from knowing dependency hell are the age of the ecosystem and the fact that there are not that many common package publishers outside of the core team.