If changing an external API would break existing applications I think it would be better to introduce a new API that has the improved behavior. Deprecate the old external API with a comment saying that you should use the new one instead. Then in the next release we can remove the old external deprecated API since users had a release to switch to the new one.
On Thu, Dec 22, 2016 at 6:57 PM, Alyssa Kim <micro9...@gmail.com> wrote: > Hi, > > Related Jira : https://issues.apache.org/jira/browse/GEODE-1577 > > Summary : Replacing wildcards with generic types requires changes in > applications that use this method. Probably there are other jiras that > update public APIs too. How do we to handle this? > 1. Just update the API whenever it's completed. > 2. Wait until a significant number of API changes are made and update at > once. > 3. Other ideas > > Description: > > We have GEODE-1577 in which we replaced wildcard return types of execute > method with generic types. This will break the existing applications that > use this method at the compilation level which is what happens every time > we update a public API. So, it is suggested that "we might want to tackle > all the function API improvements at once" to minimize complexity of > updates. > > If we do want to update all the function APIs at once, I believe we need > a list of all APIs that are expected to be updated and put on hold for > dev-completed jiras related to public API chenages until most of them are > ready to be updated. (probably somebody has to keep the track of those > issues via jira tag or label) > > Alternatively, if anyone has a good strategy to handle this (or if there > is already one), please let me know. > > > Best Regards, > Alyssa Kim >
