3 ms·

LTS would be a ton less necessary if people took backwards compat as seriously as some do. Rich Hickey has a great talk here https://www.youtube.com/watch?v=oy

LTS would be a ton less necessary if people took backwards compat as seriously as some do. Rich Hickey has a great talk here https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk That said, doesn't work at all levels, but in general it's not nearly common enough in the ecosystem to keep compat consistent. When I think of libraries I love to use, I think mostly of libraries where compat is very well maintained. Package management systems tend to be working against you here. Bumping major versions for "good" reasons makes it so that your biggest library users just get stuck, because they have so much code in the old paradigm. Real compat changes deserve new names/namespaces, so that you can progressively upgrade.

moomin 9y ago
Backwards compatibility is exactly why clojure.set’s JIRA is full of won’t fixes, though. It’s not just a cost for maintainers.
- bpicolo 9y ago
  Yeah, for sure. I think the best takeaway for me from that talk was that major versioning is actually a kinda crummy part of dependency managers, because the way we structure them / code tends to allow you to only use one version of some library at a time. I've definitely been bit on many occasions by libraries doing entire restructures of the whole thing and then pushing under the same namespace. A better strategy for namespacing would go a long way. The clojure.set thing is crummy but a hard call. That's a super fundamental piece of the library puzzle, and write once, run forever is a really very expected thing there. Those are something that a wrapper can overcome pretty simply though. In a lot of those cases the approach they take does seem reasonable though, namely that e.g. clojure.set/union perform exactly as is documented on the documented inputs.

3 ms·

LTS would be a ton less necessary if people took backwards compat as seriously as some do. Rich Hickey has a great talk here https://www.youtube.com/watch?v=oy

by bpicolo 9y ago

moomin 9y ago
Backwards compatibility is exactly why clojure.set’s JIRA is full of won’t fixes, though. It’s not just a cost for maintainers.
- bpicolo 9y ago
  Yeah, for sure. I think the best takeaway for me from that talk was that major versioning is actually a kinda crummy part of dependency managers, because the way we structure them / code tends to allow you to only use one version of some library at a time. I've definitely been bit on many occasions by libraries doing entire restructures of the whole thing and then pushing under the same namespace. A better strategy for namespacing would go a long way. The clojure.set thing is crummy but a hard call. That's a super fundamental piece of the library puzzle, and write once, run forever is a really very expected thing there. Those are something that a wrapper can overcome pretty simply though. In a lot of those cases the approach they take does seem reasonable though, namely that e.g. clojure.set/union perform exactly as is documented on the documented inputs.