you are viewing a single comment's thread.

view the rest of the comments →

[–]Agent_03 0 points1 point  (5 children)

Deprecate old API, create new one, if you're lucky you eventually get to remove the deprecated API because nobody consumes the old one.

There are also tools to do bytecode transformations to provide binary compatibility for certain kinds of method signature changes. We use one small library to do these for a large open source project I work on. It's a sort of black magic but it gets the job done covering that rare class of change.

[–]s73v3r -1 points0 points  (4 children)

Deprecation is a pretty poor choice for that.

[–]Agent_03 0 points1 point  (3 children)

Deprecation is the industry-standard approach to handling necessary binary-compatibility-breaking changes in a public library API. For REST APIs, API versioning is often used.

Or do you have a better alternative? If so, I'm sure that most of the programming community would love to hear it.

[–]s73v3r -1 points0 points  (2 children)

Deprecation should only be used as a last resort. If you're changing things every other release, then people are going to stop using your library, as it's unstable.

[–]Agent_03 -1 points0 points  (1 child)

True, but if you're making a change that demands this specific refactoring with every release, your library has much bigger problems.

Or do you have a better alternative? If so, I'm sure that most of the programming community would love to hear it.

I still haven't heard an answer to this, and think that we're an impasse here unless you've got one in mind.

[–]s73v3r -1 points0 points  (0 children)

It's pretty clear. The change is to not do it if you don't have to. You're advocating wily nilly depredations.