Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Flat Records #375
toolbear left a comment
Instead of adapting the existing incremental producer, should we instead build up a new replacement API? That way we can deprecate the current API as-is without introducing any changes to it. Also, I wonder if there are features in the current API that we'd like to abandon. Or if it's just easier to iterate on the design without being encumbered by choices in the current implementation.
If we want to go the route of introducing a new
I don't know if this lines up with the changes Paul had in mind. If the new API is far more similar to the current API then maybe it's a bad idea to fork the classes. I want to be able to release without having to disrupt Target or anyone else using the current API until we have an incremental producer that's a mature replacement for the "beta" one we already released.
Alternatively, we could do as we warned we might and make any breaking changes we need, suggesting that people fork the older API if they need it or await a mature release of the new API.