3 ms·
This reminds me of Rich Hickey's keynote called "Spec-ulation": https://www.youtube.com/watch?v=oyLBGkS5ICk&t=0s https://www.youtube.com/watch?v=oyLBGkS5ICk&t=0
by bad_user 10y ago
This reminds me of Rich Hickey's keynote called "Spec-ulation": https://www.youtube.com/watch?v=oyLBGkS5ICk&t=0s https://www.youtube.com/watch?v=oyLBGkS5ICk&t=0s
He's classifying changes in library as either:
- (backwards compatible) growth
- breakage
He's also saying that "semantic versioning" is a recipe for breaking people's software and that if you're going to break things, then you should change the name / namespace. I agree with him.
- Chyzwar 10y agoProblem is not semantic version but .Net platform that have multiple branches of the same thing[0]. If MS was not braindead they would promote Mono to become .Net Core instead of building a new thing. Hickey's Clojure introduce breaking changes even in minor versions[1] how this is more sensible?. [0]https://docs.microsoft.com/en-us/dotnet/articles/standard/library https://docs.microsoft.com/en-us/dotnet/articles/standard/li... [1]https://github.com/clojure/clojure/blob/master/changes.md https://github.com/clojure/clojure/blob/master/changes.md
- bad_user 10y agoEven though its history isn't perfect, Clojure's changes are not breaking and it's one of those projects that sets a high bar for what backwards compatibility means. Clojure code written for 1.0 (May 2009) works just fine in Clojure 1.8 and you'd find it challenging to find an item in that linked document that actually breaks compatibility.
- _pmf_ 10y agoIt's an unfortunate side effect of the limited way some ecosystems handle multi-version dependencies; I would not blame this on semantic versioning (which clearly states which changes are to be considered breaking). With OSGi I can use one module that uses an older version and one module that uses a newer version and use these together in an application (as long as the dependencies are not exposed, which they unfortunately will be in almost all real-world code).