←back to thread

45 points scolby33 | 7 comments | | HN request time: 0.528s | source | bottom
1. superkuh ◴[] No.46220253[source]
>We ended up adding the APIs back and creating a hurried release to fix the issue.

So it was entirely possible to keep the software working with these. Why change/remove them in the first place? Is the benefit of of the new abstraction greater than the downside of requiring everyone using the software to re-write theirs?

replies(2): >>46220931 #>>46221520 #
2. integralid ◴[] No.46220931[source]
OS software maintainers don't like maintaining legacy ugly APIs forever and want to refactor/remove legacy code to keep themselves sane and the project maintainable.
replies(3): >>46221115 #>>46221398 #>>46224920 #
3. superkuh ◴[] No.46221115[source]
Yep. Or you can see it as, "This software doesn't really care about the users and their use cases. It prioritizes making things look pretty and easier on the dev side over maintaining functionality." Or in the worse but fairly common OSS case, CADT, but that doesn't seem to apply in this context.
4. LegionMammal978 ◴[] No.46221398[source]
Every public API change is a cost on the user: for an extreme example, if every library I ever used renamed half its APIs every year to align with the latest ontology, then there would hardly be any point in saving my scripts, since I'd have to be constantly rewriting them all.

Of course, the reality is hardly ever as bad as that, but I'd say having to deal with trivial API changes is a reasonable basis for a user to dislike a given project or try to avoid using it. It's up to the maintainers how friendly they want to be toward existing user code, and whether they pursue mitigating options like bundling migrations into less-common bigger updates.

5. memco ◴[] No.46221520[source]
I think this is a valid question for this specific case, but may not always be possible. That said, I think as a user I would probably prefer it if under the hood the old function called the new so they can deprecate the behavior without breaking the API. In that way you can still emit the deprecation warning while also only having one actual code path to maintain.
replies(1): >>46221621 #
6. shadowgovt ◴[] No.46221621[source]
Funny enough, in Python, a sufficiently-dedicated client can also do this on their end by just monkey-patching the class definition.
7. mxey ◴[] No.46224920[source]
It’s like 5 lines of code https://github.com/urllib3/urllib3/pull/3732/files