4 ms·

Suppose we replaced Semantic Versioning with any other approach (of your choice) that still disclosed the same amount of information about whether API was ident

by pryce 8y ago

Suppose we replaced Semantic Versioning with any other approach (of your choice) that still disclosed the same amount of information about whether API was identical, had an additive change, or had a breaking change. Would you object to that model too ? If so, it seems like you'd be effectively arguing that authors should simply not disclose important changes to the API. It is hard to imagine that position being defensible. If not, why do you consider Semantic Versioning to be more hazardous?

badsectoracula 8y ago
I think the idea (with which i fully agree, btw) is to avoid at all technically possible costs to make backwards incompatible changes in the first place (and when they happen they should be considered as nothing more than bugs to be fixed - ie. restore the backwards compatibility) and the semantics of semver are trying to represent some state that shouldn't be representable at all. Think of it as a reference in C++ that is null... it can technically happen (in the sense that all bytes that store the reference are, e.g., zero), but the language doesn't really allow for it and if it does happen it is a bug.
anth_anm 8y ago
You make a design decision and you should be stuck with it forever. You build your own hell one mistake at a time. If you don't like it, quit in shame instead.
brudgers 8y ago
Additive changes aren't a problem. If I use the method 'spam' from library '{foo : most_recent}' adding 'eggs' to 'foo' doesn't require me to edit my code to {foo : 16.8.37}. The most recent version still works. If the library author decides to do something that breaks calls to 'spam' (or 'eggs', etc.) then a protocol that calls the new library 'foobar' (not 'foo') means '{foo : most_recent}' still works. I can use continue using 'foo.spam' if it meets my needs. + And there's no problem if I want to add '{foobar : most_recent}' to the code if I want to use 'foobar.eggs'. + And I can even use 'foobar.spam' alongside 'foo.spam'. + And my build system can be simplified to '{foo}, {foobar}' as the ordinary case. With language like '{foo : 23.8.13}' only needed for rare cases. For example when my code depends on the effects of an obvious bug that was patched. The premise of semantic versioning is that breaking changes for whatever reason are ok. And look, that's fine. "It's your library. It's free. You don't owe me anything." I just prefer not to rely on people who will change "print x" to "print(x)" based on divine revelation rather than the effect it has on everyone who relied on the documentation saying use 'print x'. And no automated migration tools because semantic versioning.

by pryce 8y ago

badsectoracula 8y ago

I think the idea (with which i fully agree, btw) is to avoid at all technically possible costs to make backwards incompatible changes in the first place (and when they happen they should be considered as nothing more than bugs to be fixed - ie. restore the backwards compatibility) and the semantics of semver are trying to represent some state that shouldn't be representable at all. Think of it as a reference in C++ that is null... it can technically happen (in the sense that all bytes that store the reference are, e.g., zero), but the language doesn't really allow for it and if it does happen it is a bug.

anth_anm 8y ago

You make a design decision and you should be stuck with it forever. You build your own hell one mistake at a time. If you don't like it, quit in shame instead.

brudgers 8y ago

Additive changes aren't a problem. If I use the method 'spam' from library '{foo : most_recent}' adding 'eggs' to 'foo' doesn't require me to edit my code to {foo : 16.8.37}. The most recent version still works. If the library author decides to do something that breaks calls to 'spam' (or 'eggs', etc.) then a protocol that calls the new library 'foobar' (not 'foo') means '{foo : most_recent}' still works. I can use continue using 'foo.spam' if it meets my needs. + And there's no problem if I want to add '{foobar : most_recent}' to the code if I want to use 'foobar.eggs'. + And I can even use 'foobar.spam' alongside 'foo.spam'. + And my build system can be simplified to '{foo}, {foobar}' as the ordinary case. With language like '{foo : 23.8.13}' only needed for rare cases. For example when my code depends on the effects of an obvious bug that was patched. The premise of semantic versioning is that breaking changes for whatever reason are ok. And look, that's fine. "It's your library. It's free. You don't owe me anything." I just prefer not to rely on people who will change "print x" to "print(x)" based on divine revelation rather than the effect it has on everyone who relied on the documentation saying use 'print x'. And no automated migration tools because semantic versioning.