You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Alyssa Kim <mi...@gmail.com> on 2016/12/23 02:57:20 UTC
Strategy for Updating Public API Changes
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
Re: Strategy for Updating Public API Changes
Posted by Michael Stolz <ms...@pivotal.io>.
+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" <ds...@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 <mi...@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
> >
>
Re: Strategy for Updating Public API Changes
Posted by Anthony Baker <ab...@pivotal.io>.
I agree with Darrel. I’m not a big fan of the current Fn API for a variety
of reasons, not least of which is the annoyingly inconsistent use of
generics that Ayssa was trying to fix.
I think a newer take on this API should include support for lambdas and
Stream / Reactive patterns.
Anthony
On Dec 23, 2016, at 11:37 AM, Darrel Schneider <ds...@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 <mi...@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
Re: Strategy for Updating Public API Changes
Posted by Anthony Baker <ab...@pivotal.io>.
I agree with Darrel. I’m not a big fan of the current Fn API for a variety of reasons, not least of which is the annoyingly inconsistent use of generics that Ayssa was trying to fix.
I think a newer take on this API should include support for lambdas and Stream / Reactive patterns.
Anthony
> On Dec 23, 2016, at 11:37 AM, Darrel Schneider <ds...@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 <mi...@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
>>
Re: Strategy for Updating Public API Changes
Posted by Darrel Schneider <ds...@pivotal.io>.
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 <mi...@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
>