You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@reef.apache.org by Byung-Gon Chun <bg...@gmail.com> on 2015/08/03 14:17:25 UTC
deprecated code
Hi,
It looks like it's too much work for a release manager to handle deprecated
code.
It seems to be natural for one who added @Deprecated (or did work on the
part) to handle the task. :)
Thought?
-Gon
--
Byung-Gon Chun
Re: deprecated code
Posted by Markus Weimer <ma...@weimo.de>.
On 2015-08-03 08:30, Markus Weimer wrote:
> Shall we add these two rules to the contributor guide?
I just did:
https://cwiki.apache.org/confluence/display/REEF/Coding+Guidelines
Please have a look and improve the language, if you can :-)
Markus
RE: deprecated code
Posted by "Julia Wang (QIUHE)" <Qi...@microsoft.com>.
The document looks good.
Regarding "Make sure that all current uses of that API in REEF have either been moved to the new API or been deprecated as well.", for some bigger changes, our code especially test code may use deprecated API, if we are not able to remove the deprecated API usage at once, we need to:
*File JIRAs for all the code in REEF that uses the deprecated API and link those JIRAs to a main JIRA regarding the API deprecation
*Be responsible for the follow up of those JIRAS.
Thanks,
Julia
-----Original Message-----
From: Brian Cho [mailto:chobrian@gmail.com]
Sent: Monday, August 3, 2015 7:37 PM
To: dev@reef.incubator.apache.org
Subject: Re: deprecated code
Yes, here’s the overall plan (from REEF-497):
1. A best effort is made to remove as many deprecated parts as possible.
2. For the ones that can't be removed, we should either annotate them
and those methods that are blocking them as "deprecated since 0.12" or
upgrade them to non-deprecated if they are still heavily used. In the
process we introduce issues to be worked out before 0.13.
For part 1, I’ve opened a PR for REEF-552, and Mariia has already closed some issues and is doing work on REEF-557. I’d like to get these two JIRAs in if possible.
Part 2 will be an ongoing effort, so it shouldn’t block releasing 0.12.
-Brian
On Tue, Aug 4, 2015 at 6:50 AM, Byung-Gon Chun <bg...@gmail.com> wrote:
> That leads to my other question.
>
> Brian, can you decide deprecation we will handle for the current
> release and move on?
> We can address unhandled ones in 0.13.
>
>
>
> On Tue, Aug 4, 2015 at 6:45 AM, Markus Weimer <ma...@weimo.de> wrote:
>
> > On 2015-08-03 14:37, Byung-Gon Chun wrote:
> > > Can I suggest that we start to handle removing deprecated code at
> > > least
> > two
> > > or three weeks before the target release date? In this way, we can
> avoid
> > > delaying our release.
> >
> > I don't think removing deprecated code should block a release. Worst
> > case, we have a few APIs still in the code where we didn't promise
> > to still have them.
> >
> > That said, I agree with acting on deprecations much earlier,
> > preferably right *after* a release.
> >
> > Markus
> >
>
>
>
> --
> Byung-Gon Chun
>
Re: deprecated code
Posted by Brian Cho <ch...@gmail.com>.
Yes, here’s the overall plan (from REEF-497):
1. A best effort is made to remove as many deprecated parts as possible.
2. For the ones that can't be removed, we should either annotate them
and those methods that are blocking them as "deprecated since 0.12" or
upgrade them to non-deprecated if they are still heavily used. In the
process we introduce issues to be worked out before 0.13.
For part 1, I’ve opened a PR for REEF-552, and Mariia has already closed
some issues and is doing work on REEF-557. I’d like to get these two JIRAs
in if possible.
Part 2 will be an ongoing effort, so it shouldn’t block releasing 0.12.
-Brian
On Tue, Aug 4, 2015 at 6:50 AM, Byung-Gon Chun <bg...@gmail.com> wrote:
> That leads to my other question.
>
> Brian, can you decide deprecation we will handle for the current release
> and move on?
> We can address unhandled ones in 0.13.
>
>
>
> On Tue, Aug 4, 2015 at 6:45 AM, Markus Weimer <ma...@weimo.de> wrote:
>
> > On 2015-08-03 14:37, Byung-Gon Chun wrote:
> > > Can I suggest that we start to handle removing deprecated code at least
> > two
> > > or three weeks before the target release date? In this way, we can
> avoid
> > > delaying our release.
> >
> > I don't think removing deprecated code should block a release. Worst
> > case, we have a few APIs still in the code where we didn't promise to
> > still have them.
> >
> > That said, I agree with acting on deprecations much earlier, preferably
> > right *after* a release.
> >
> > Markus
> >
>
>
>
> --
> Byung-Gon Chun
>
Re: deprecated code
Posted by Byung-Gon Chun <bg...@gmail.com>.
That leads to my other question.
Brian, can you decide deprecation we will handle for the current release
and move on?
We can address unhandled ones in 0.13.
On Tue, Aug 4, 2015 at 6:45 AM, Markus Weimer <ma...@weimo.de> wrote:
> On 2015-08-03 14:37, Byung-Gon Chun wrote:
> > Can I suggest that we start to handle removing deprecated code at least
> two
> > or three weeks before the target release date? In this way, we can avoid
> > delaying our release.
>
> I don't think removing deprecated code should block a release. Worst
> case, we have a few APIs still in the code where we didn't promise to
> still have them.
>
> That said, I agree with acting on deprecations much earlier, preferably
> right *after* a release.
>
> Markus
>
--
Byung-Gon Chun
Re: deprecated code
Posted by Markus Weimer <ma...@weimo.de>.
On 2015-08-03 14:37, Byung-Gon Chun wrote:
> Can I suggest that we start to handle removing deprecated code at least two
> or three weeks before the target release date? In this way, we can avoid
> delaying our release.
I don't think removing deprecated code should block a release. Worst
case, we have a few APIs still in the code where we didn't promise to
still have them.
That said, I agree with acting on deprecations much earlier, preferably
right *after* a release.
Markus
Re: deprecated code
Posted by Byung-Gon Chun <bg...@gmail.com>.
On Tue, Aug 4, 2015 at 6:37 AM, Byung-Gon Chun <bg...@gmail.com> wrote:
> The two rules are good.
>
> Can I suggest that we start to handle removing deprecated code at least
> two or three weeks before the target release date? In this way, we can
> avoid delaying our release.
> I expect that if we address all the deprecation issues our release will be
> delayed quite a bit (maybe late August pessimistically).
>
> the current release
>
>
>
> On Tue, Aug 4, 2015 at 12:30 AM, Markus Weimer <ma...@weimo.de> wrote:
>
>> On 2015-08-03 08:26, Brian Cho wrote:
>> > I'd like to suggest another guideline as well: the author who
>> > deprecates needs to check that all usage in REEF of the method/class
>> > is either removed or itself part of a deprecated method/class.
>>
>> Yes, excellent suggestion. Otherwise, deprecations will just continue to
>> pile up.
>>
>> Shall we add these two rules to the contributor guide?
>>
>> Markus
>>
>
>
>
> --
> Byung-Gon Chun
>
--
Byung-Gon Chun
Re: deprecated code
Posted by Byung-Gon Chun <bg...@gmail.com>.
The two rules are good.
Can I suggest that we start to handle removing deprecated code at least two
or three weeks before the target release date? In this way, we can avoid
delaying our release.
I expect that if we address all the deprecation issues our release will be
delayed quite a bit (maybe late August pessimistically).
On Tue, Aug 4, 2015 at 12:30 AM, Markus Weimer <ma...@weimo.de> wrote:
> On 2015-08-03 08:26, Brian Cho wrote:
> > I'd like to suggest another guideline as well: the author who
> > deprecates needs to check that all usage in REEF of the method/class
> > is either removed or itself part of a deprecated method/class.
>
> Yes, excellent suggestion. Otherwise, deprecations will just continue to
> pile up.
>
> Shall we add these two rules to the contributor guide?
>
> Markus
>
--
Byung-Gon Chun
Re: deprecated code
Posted by Markus Weimer <ma...@weimo.de>.
On 2015-08-03 08:26, Brian Cho wrote:
> I'd like to suggest another guideline as well: the author who
> deprecates needs to check that all usage in REEF of the method/class
> is either removed or itself part of a deprecated method/class.
Yes, excellent suggestion. Otherwise, deprecations will just continue to
pile up.
Shall we add these two rules to the contributor guide?
Markus
Re: deprecated code
Posted by Brian Cho <ch...@gmail.com>.
Yes that makes sense.
I'd like to suggest another guideline as well: the author who deprecates needs to check that all usage in REEF of the method/class is either removed or itself part of a deprecated method/class.
Thanks,Brian
_____________________________
From: Markus Weimer <ma...@weimo.de>
Sent: Monday, August 3, 2015 11:57 PM
Subject: Re: deprecated code
To: <de...@reef.incubator.apache.org>
On 2015-08-03 05:17, Byung-Gon Chun wrote:
> It looks like it's too much work for a release manager to handle deprecated
> code.
Agreed.
> It seems to be natural for one who added @Deprecated (or did work on the
> part) to handle the task. :)
Yes, sounds reasonable. However, we have to be more careful in future
deprecations. I suggest that we make it a rule to always file a JIRA to
remove the deprecated code *when we deprecate it*. That way, we can
track all the removals are a more fine-grained level. Also, we can mark
that JIRA as blocked on the next release and other JIRAs it depends on.
Makes sense?
Markus
Re: deprecated code
Posted by Markus Weimer <ma...@weimo.de>.
On 2015-08-03 05:17, Byung-Gon Chun wrote:
> It looks like it's too much work for a release manager to handle deprecated
> code.
Agreed.
> It seems to be natural for one who added @Deprecated (or did work on the
> part) to handle the task. :)
Yes, sounds reasonable. However, we have to be more careful in future
deprecations. I suggest that we make it a rule to always file a JIRA to
remove the deprecated code *when we deprecate it*. That way, we can
track all the removals are a more fine-grained level. Also, we can mark
that JIRA as blocked on the next release and other JIRAs it depends on.
Makes sense?
Markus