+1 that's exactly what deprecation is for -- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Dec 23, 2016 2:37 PM, "Darrel Schneider" <dschnei...@pivotal.io> wrote:
> 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 > > >
