You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mxnet.apache.org by Lin Yuan <ap...@gmail.com> on 2019/02/28 04:52:59 UTC
[DISCUSS] Process to remove deprecated operators
Dear Community,
In MXNet there are many legacy operators such as this
<http://mxnet.incubator.apache.org/versions/master/api/python/symbol/symbol.html?highlight=convolution_v1#mxnet.symbol.Convolution_v1>
that has been marked DEPRECATE for several releases. However, these
operators still exist in our code. This caused a few problems:
1) Make the codebase bloated and reduce readability
2) Increase unnecessary maintanence effort
3) Bug prone as some people will look up these legacy code as example
4) Cause confusion to end users and make documentation page lengthy
I would like to propose the following process (if there is no existing one)
to remove deprecate operators from our code base.
1. Documnent the deprecate operators/environment variables in the release
note as well as man pages.
2. Limit the life cycle of deprecate operators/argument to two minor
release. For example, if one operator is marked deprecate in 1.4 release,
it will be removed in 1.6 release.
3. If there is some concern raised from customers during 1.4 and 1.5
release, we can convert the deprecated operator back to current and it will
be treated as new operator.
4. PRs that remove deprecate operators should contain [Cleanup] in title.
Any comment is appreciated.
Lin
Re: [DISCUSS] Process to remove deprecated operators
Posted by Naveen Swamy <mn...@gmail.com>.
It might be a good idea to issue those deprecation messages right away if
have replacement operators already, so users get enough time to migrate to
the new operators.
On Thu, Feb 28, 2019 at 2:45 PM Anirudh Acharya <an...@gmail.com>
wrote:
> Hi Lin,
>
> This is a good idea. Here is an issue -
> https://github.com/apache/incubator-mxnet/issues/9686 that is already
> attempting to collate all the breaking changes that might be necessary for
> v2.0. We could start by adding things to that issue.
>
> I think eventually we will need a separate branch into which these breaking
> changes get introduced, and this branch can later be merged into master
> prior to v2.0 release.
>
> Thanks
> Anirudh
>
>
> On Thu, Feb 28, 2019 at 1:35 PM Wen-Yang Chu <we...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I have raised an issue:
> >
> > mx.nd.Crop does not support FP16 and decpreciated but no direct
> alternative
> > with central crop
> > I use this operator to implement Unet and I found other people too on the
> > Internent. It is very inconvenient to remove this specific operator
> > withoit clear alternative for me:
> >
> > https://github.com/apache/incubator-mxnet/issues/13750
> >
> > *Is it possible to review depreciated operators to make sure we have
> > equivalent functionality?*
> > Thanks
> >
> > Wen-Yang
> >
> > On Thu, Feb 28, 2019 at 2:07 PM Chaitanya Bapat <ch...@gmail.com>
> > wrote:
> >
> > > This sounds good.
> > > Going further, if we can maintain a list of deprecated operators - we
> can
> > > create a "Good for first contribution" issue to improve log messaging
> of
> > > Deprecated operators.
> > > If it makes sense, I can go ahead and create that.
> > >
> > > Hope this helps.
> > >
> > > On Thu, 28 Feb 2019 at 01:54, Lin Yuan <ap...@gmail.com> wrote:
> > >
> > > > Agreed. When we deprecate an operator, we should add in the log
> message
> > > > something like "This operator X is deprecate and will be removed in
> the
> > > > next release. Please use operator Y instead."
> > > >
> > > > Lin
> > > >
> > > > On Wed, Feb 27, 2019 at 10:23 PM Junru Shao <junrushao1994@gmail.com
> >
> > > > wrote:
> > > >
> > > > > Hi Lin,
> > > > >
> > > > > I would love to share some immature ideas about deprecating
> > operators.
> > > > Not
> > > > > only adopting semantic versioning, but also should we provide
> enough
> > > > > informative error message for customers to understand how to
> replace
> > > > > deprecated operators with new ones.
> > > > >
> > > > > Thanks,
> > > > > Junru
> > > > >
> > > > > On Wed, Feb 27, 2019 at 9:30 PM Lin Yuan <ap...@gmail.com>
> > wrote:
> > > > >
> > > > > > Sheng,
> > > > > >
> > > > > > Thanks for your quick response.
> > > > > > If that's the case, we will wait till 2.0 release to remove the
> > > > > deprecated
> > > > > > operators from code.
> > > > > >
> > > > > > Best,
> > > > > > Lin
> > > > > >
> > > > > > On Wed, Feb 27, 2019 at 9:06 PM Sheng Zha <zh...@apache.org>
> > > wrote:
> > > > > >
> > > > > > > MXNet follows semantic versioning so we will be able to delete
> > them
> > > > in
> > > > > > the
> > > > > > > next major release.
> > > > > > >
> > > > > > > -sz
> > > > > > >
> > > > > > > On Wed, Feb 27, 2019 at 8:53 PM Lin Yuan <ap...@gmail.com>
> > > > wrote:
> > > > > > >
> > > > > > > > Dear Community,
> > > > > > > >
> > > > > > > > In MXNet there are many legacy operators such as this
> > > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://mxnet.incubator.apache.org/versions/master/api/python/symbol/symbol.html?highlight=convolution_v1#mxnet.symbol.Convolution_v1
> > > > > > > > >
> > > > > > > > that has been marked DEPRECATE for several releases. However,
> > > these
> > > > > > > > operators still exist in our code. This caused a few
> problems:
> > > > > > > >
> > > > > > > > 1) Make the codebase bloated and reduce readability
> > > > > > > > 2) Increase unnecessary maintanence effort
> > > > > > > > 3) Bug prone as some people will look up these legacy code as
> > > > example
> > > > > > > > 4) Cause confusion to end users and make documentation page
> > > lengthy
> > > > > > > >
> > > > > > > > I would like to propose the following process (if there is no
> > > > > existing
> > > > > > > one)
> > > > > > > > to remove deprecate operators from our code base.
> > > > > > > >
> > > > > > > > 1. Documnent the deprecate operators/environment variables in
> > the
> > > > > > release
> > > > > > > > note as well as man pages.
> > > > > > > > 2. Limit the life cycle of deprecate operators/argument to
> two
> > > > minor
> > > > > > > > release. For example, if one operator is marked deprecate in
> > 1.4
> > > > > > release,
> > > > > > > > it will be removed in 1.6 release.
> > > > > > > > 3. If there is some concern raised from customers during 1.4
> > and
> > > > 1.5
> > > > > > > > release, we can convert the deprecated operator back to
> current
> > > and
> > > > > it
> > > > > > > will
> > > > > > > > be treated as new operator.
> > > > > > > > 4. PRs that remove deprecate operators should contain
> [Cleanup]
> > > in
> > > > > > title.
> > > > > > > >
> > > > > > > > Any comment is appreciated.
> > > > > > > >
> > > > > > > > Lin
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > *Chaitanya Prakash Bapat*
> > > *+1 (973) 953-6299*
> > >
> > > [image: https://www.linkedin.com//in/chaibapat25]
> > > <https://github.com/ChaiBapchya>[image:
> > https://www.facebook.com/chaibapat
> > > ]
> > > <https://www.facebook.com/chaibapchya>[image:
> > > https://twitter.com/ChaiBapchya] <https://twitter.com/ChaiBapchya
> > >[image:
> > > https://www.linkedin.com//in/chaibapat25]
> > > <https://www.linkedin.com//in/chaibapchya/>
> > >
> >
>
Re: [DISCUSS] Process to remove deprecated operators
Posted by Anirudh Acharya <an...@gmail.com>.
Hi Lin,
This is a good idea. Here is an issue -
https://github.com/apache/incubator-mxnet/issues/9686 that is already
attempting to collate all the breaking changes that might be necessary for
v2.0. We could start by adding things to that issue.
I think eventually we will need a separate branch into which these breaking
changes get introduced, and this branch can later be merged into master
prior to v2.0 release.
Thanks
Anirudh
On Thu, Feb 28, 2019 at 1:35 PM Wen-Yang Chu <we...@gmail.com> wrote:
> Hi,
>
> I have raised an issue:
>
> mx.nd.Crop does not support FP16 and decpreciated but no direct alternative
> with central crop
> I use this operator to implement Unet and I found other people too on the
> Internent. It is very inconvenient to remove this specific operator
> withoit clear alternative for me:
>
> https://github.com/apache/incubator-mxnet/issues/13750
>
> *Is it possible to review depreciated operators to make sure we have
> equivalent functionality?*
> Thanks
>
> Wen-Yang
>
> On Thu, Feb 28, 2019 at 2:07 PM Chaitanya Bapat <ch...@gmail.com>
> wrote:
>
> > This sounds good.
> > Going further, if we can maintain a list of deprecated operators - we can
> > create a "Good for first contribution" issue to improve log messaging of
> > Deprecated operators.
> > If it makes sense, I can go ahead and create that.
> >
> > Hope this helps.
> >
> > On Thu, 28 Feb 2019 at 01:54, Lin Yuan <ap...@gmail.com> wrote:
> >
> > > Agreed. When we deprecate an operator, we should add in the log message
> > > something like "This operator X is deprecate and will be removed in the
> > > next release. Please use operator Y instead."
> > >
> > > Lin
> > >
> > > On Wed, Feb 27, 2019 at 10:23 PM Junru Shao <ju...@gmail.com>
> > > wrote:
> > >
> > > > Hi Lin,
> > > >
> > > > I would love to share some immature ideas about deprecating
> operators.
> > > Not
> > > > only adopting semantic versioning, but also should we provide enough
> > > > informative error message for customers to understand how to replace
> > > > deprecated operators with new ones.
> > > >
> > > > Thanks,
> > > > Junru
> > > >
> > > > On Wed, Feb 27, 2019 at 9:30 PM Lin Yuan <ap...@gmail.com>
> wrote:
> > > >
> > > > > Sheng,
> > > > >
> > > > > Thanks for your quick response.
> > > > > If that's the case, we will wait till 2.0 release to remove the
> > > > deprecated
> > > > > operators from code.
> > > > >
> > > > > Best,
> > > > > Lin
> > > > >
> > > > > On Wed, Feb 27, 2019 at 9:06 PM Sheng Zha <zh...@apache.org>
> > wrote:
> > > > >
> > > > > > MXNet follows semantic versioning so we will be able to delete
> them
> > > in
> > > > > the
> > > > > > next major release.
> > > > > >
> > > > > > -sz
> > > > > >
> > > > > > On Wed, Feb 27, 2019 at 8:53 PM Lin Yuan <ap...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > Dear Community,
> > > > > > >
> > > > > > > In MXNet there are many legacy operators such as this
> > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://mxnet.incubator.apache.org/versions/master/api/python/symbol/symbol.html?highlight=convolution_v1#mxnet.symbol.Convolution_v1
> > > > > > > >
> > > > > > > that has been marked DEPRECATE for several releases. However,
> > these
> > > > > > > operators still exist in our code. This caused a few problems:
> > > > > > >
> > > > > > > 1) Make the codebase bloated and reduce readability
> > > > > > > 2) Increase unnecessary maintanence effort
> > > > > > > 3) Bug prone as some people will look up these legacy code as
> > > example
> > > > > > > 4) Cause confusion to end users and make documentation page
> > lengthy
> > > > > > >
> > > > > > > I would like to propose the following process (if there is no
> > > > existing
> > > > > > one)
> > > > > > > to remove deprecate operators from our code base.
> > > > > > >
> > > > > > > 1. Documnent the deprecate operators/environment variables in
> the
> > > > > release
> > > > > > > note as well as man pages.
> > > > > > > 2. Limit the life cycle of deprecate operators/argument to two
> > > minor
> > > > > > > release. For example, if one operator is marked deprecate in
> 1.4
> > > > > release,
> > > > > > > it will be removed in 1.6 release.
> > > > > > > 3. If there is some concern raised from customers during 1.4
> and
> > > 1.5
> > > > > > > release, we can convert the deprecated operator back to current
> > and
> > > > it
> > > > > > will
> > > > > > > be treated as new operator.
> > > > > > > 4. PRs that remove deprecate operators should contain [Cleanup]
> > in
> > > > > title.
> > > > > > >
> > > > > > > Any comment is appreciated.
> > > > > > >
> > > > > > > Lin
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > *Chaitanya Prakash Bapat*
> > *+1 (973) 953-6299*
> >
> > [image: https://www.linkedin.com//in/chaibapat25]
> > <https://github.com/ChaiBapchya>[image:
> https://www.facebook.com/chaibapat
> > ]
> > <https://www.facebook.com/chaibapchya>[image:
> > https://twitter.com/ChaiBapchya] <https://twitter.com/ChaiBapchya
> >[image:
> > https://www.linkedin.com//in/chaibapat25]
> > <https://www.linkedin.com//in/chaibapchya/>
> >
>
Re: [DISCUSS] Process to remove deprecated operators
Posted by Wen-Yang Chu <we...@gmail.com>.
Hi,
I have raised an issue:
mx.nd.Crop does not support FP16 and decpreciated but no direct alternative
with central crop
I use this operator to implement Unet and I found other people too on the
Internent. It is very inconvenient to remove this specific operator
withoit clear alternative for me:
https://github.com/apache/incubator-mxnet/issues/13750
*Is it possible to review depreciated operators to make sure we have
equivalent functionality?*
Thanks
Wen-Yang
On Thu, Feb 28, 2019 at 2:07 PM Chaitanya Bapat <ch...@gmail.com>
wrote:
> This sounds good.
> Going further, if we can maintain a list of deprecated operators - we can
> create a "Good for first contribution" issue to improve log messaging of
> Deprecated operators.
> If it makes sense, I can go ahead and create that.
>
> Hope this helps.
>
> On Thu, 28 Feb 2019 at 01:54, Lin Yuan <ap...@gmail.com> wrote:
>
> > Agreed. When we deprecate an operator, we should add in the log message
> > something like "This operator X is deprecate and will be removed in the
> > next release. Please use operator Y instead."
> >
> > Lin
> >
> > On Wed, Feb 27, 2019 at 10:23 PM Junru Shao <ju...@gmail.com>
> > wrote:
> >
> > > Hi Lin,
> > >
> > > I would love to share some immature ideas about deprecating operators.
> > Not
> > > only adopting semantic versioning, but also should we provide enough
> > > informative error message for customers to understand how to replace
> > > deprecated operators with new ones.
> > >
> > > Thanks,
> > > Junru
> > >
> > > On Wed, Feb 27, 2019 at 9:30 PM Lin Yuan <ap...@gmail.com> wrote:
> > >
> > > > Sheng,
> > > >
> > > > Thanks for your quick response.
> > > > If that's the case, we will wait till 2.0 release to remove the
> > > deprecated
> > > > operators from code.
> > > >
> > > > Best,
> > > > Lin
> > > >
> > > > On Wed, Feb 27, 2019 at 9:06 PM Sheng Zha <zh...@apache.org>
> wrote:
> > > >
> > > > > MXNet follows semantic versioning so we will be able to delete them
> > in
> > > > the
> > > > > next major release.
> > > > >
> > > > > -sz
> > > > >
> > > > > On Wed, Feb 27, 2019 at 8:53 PM Lin Yuan <ap...@gmail.com>
> > wrote:
> > > > >
> > > > > > Dear Community,
> > > > > >
> > > > > > In MXNet there are many legacy operators such as this
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> http://mxnet.incubator.apache.org/versions/master/api/python/symbol/symbol.html?highlight=convolution_v1#mxnet.symbol.Convolution_v1
> > > > > > >
> > > > > > that has been marked DEPRECATE for several releases. However,
> these
> > > > > > operators still exist in our code. This caused a few problems:
> > > > > >
> > > > > > 1) Make the codebase bloated and reduce readability
> > > > > > 2) Increase unnecessary maintanence effort
> > > > > > 3) Bug prone as some people will look up these legacy code as
> > example
> > > > > > 4) Cause confusion to end users and make documentation page
> lengthy
> > > > > >
> > > > > > I would like to propose the following process (if there is no
> > > existing
> > > > > one)
> > > > > > to remove deprecate operators from our code base.
> > > > > >
> > > > > > 1. Documnent the deprecate operators/environment variables in the
> > > > release
> > > > > > note as well as man pages.
> > > > > > 2. Limit the life cycle of deprecate operators/argument to two
> > minor
> > > > > > release. For example, if one operator is marked deprecate in 1.4
> > > > release,
> > > > > > it will be removed in 1.6 release.
> > > > > > 3. If there is some concern raised from customers during 1.4 and
> > 1.5
> > > > > > release, we can convert the deprecated operator back to current
> and
> > > it
> > > > > will
> > > > > > be treated as new operator.
> > > > > > 4. PRs that remove deprecate operators should contain [Cleanup]
> in
> > > > title.
> > > > > >
> > > > > > Any comment is appreciated.
> > > > > >
> > > > > > Lin
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> *Chaitanya Prakash Bapat*
> *+1 (973) 953-6299*
>
> [image: https://www.linkedin.com//in/chaibapat25]
> <https://github.com/ChaiBapchya>[image: https://www.facebook.com/chaibapat
> ]
> <https://www.facebook.com/chaibapchya>[image:
> https://twitter.com/ChaiBapchya] <https://twitter.com/ChaiBapchya>[image:
> https://www.linkedin.com//in/chaibapat25]
> <https://www.linkedin.com//in/chaibapchya/>
>
Re: [DISCUSS] Process to remove deprecated operators
Posted by Chaitanya Bapat <ch...@gmail.com>.
This sounds good.
Going further, if we can maintain a list of deprecated operators - we can
create a "Good for first contribution" issue to improve log messaging of
Deprecated operators.
If it makes sense, I can go ahead and create that.
Hope this helps.
On Thu, 28 Feb 2019 at 01:54, Lin Yuan <ap...@gmail.com> wrote:
> Agreed. When we deprecate an operator, we should add in the log message
> something like "This operator X is deprecate and will be removed in the
> next release. Please use operator Y instead."
>
> Lin
>
> On Wed, Feb 27, 2019 at 10:23 PM Junru Shao <ju...@gmail.com>
> wrote:
>
> > Hi Lin,
> >
> > I would love to share some immature ideas about deprecating operators.
> Not
> > only adopting semantic versioning, but also should we provide enough
> > informative error message for customers to understand how to replace
> > deprecated operators with new ones.
> >
> > Thanks,
> > Junru
> >
> > On Wed, Feb 27, 2019 at 9:30 PM Lin Yuan <ap...@gmail.com> wrote:
> >
> > > Sheng,
> > >
> > > Thanks for your quick response.
> > > If that's the case, we will wait till 2.0 release to remove the
> > deprecated
> > > operators from code.
> > >
> > > Best,
> > > Lin
> > >
> > > On Wed, Feb 27, 2019 at 9:06 PM Sheng Zha <zh...@apache.org> wrote:
> > >
> > > > MXNet follows semantic versioning so we will be able to delete them
> in
> > > the
> > > > next major release.
> > > >
> > > > -sz
> > > >
> > > > On Wed, Feb 27, 2019 at 8:53 PM Lin Yuan <ap...@gmail.com>
> wrote:
> > > >
> > > > > Dear Community,
> > > > >
> > > > > In MXNet there are many legacy operators such as this
> > > > > <
> > > > >
> > > >
> > >
> >
> http://mxnet.incubator.apache.org/versions/master/api/python/symbol/symbol.html?highlight=convolution_v1#mxnet.symbol.Convolution_v1
> > > > > >
> > > > > that has been marked DEPRECATE for several releases. However, these
> > > > > operators still exist in our code. This caused a few problems:
> > > > >
> > > > > 1) Make the codebase bloated and reduce readability
> > > > > 2) Increase unnecessary maintanence effort
> > > > > 3) Bug prone as some people will look up these legacy code as
> example
> > > > > 4) Cause confusion to end users and make documentation page lengthy
> > > > >
> > > > > I would like to propose the following process (if there is no
> > existing
> > > > one)
> > > > > to remove deprecate operators from our code base.
> > > > >
> > > > > 1. Documnent the deprecate operators/environment variables in the
> > > release
> > > > > note as well as man pages.
> > > > > 2. Limit the life cycle of deprecate operators/argument to two
> minor
> > > > > release. For example, if one operator is marked deprecate in 1.4
> > > release,
> > > > > it will be removed in 1.6 release.
> > > > > 3. If there is some concern raised from customers during 1.4 and
> 1.5
> > > > > release, we can convert the deprecated operator back to current and
> > it
> > > > will
> > > > > be treated as new operator.
> > > > > 4. PRs that remove deprecate operators should contain [Cleanup] in
> > > title.
> > > > >
> > > > > Any comment is appreciated.
> > > > >
> > > > > Lin
> > > > >
> > > >
> > >
> >
>
--
*Chaitanya Prakash Bapat*
*+1 (973) 953-6299*
[image: https://www.linkedin.com//in/chaibapat25]
<https://github.com/ChaiBapchya>[image: https://www.facebook.com/chaibapat]
<https://www.facebook.com/chaibapchya>[image:
https://twitter.com/ChaiBapchya] <https://twitter.com/ChaiBapchya>[image:
https://www.linkedin.com//in/chaibapat25]
<https://www.linkedin.com//in/chaibapchya/>
Re: [DISCUSS] Process to remove deprecated operators
Posted by Lin Yuan <ap...@gmail.com>.
Agreed. When we deprecate an operator, we should add in the log message
something like "This operator X is deprecate and will be removed in the
next release. Please use operator Y instead."
Lin
On Wed, Feb 27, 2019 at 10:23 PM Junru Shao <ju...@gmail.com> wrote:
> Hi Lin,
>
> I would love to share some immature ideas about deprecating operators. Not
> only adopting semantic versioning, but also should we provide enough
> informative error message for customers to understand how to replace
> deprecated operators with new ones.
>
> Thanks,
> Junru
>
> On Wed, Feb 27, 2019 at 9:30 PM Lin Yuan <ap...@gmail.com> wrote:
>
> > Sheng,
> >
> > Thanks for your quick response.
> > If that's the case, we will wait till 2.0 release to remove the
> deprecated
> > operators from code.
> >
> > Best,
> > Lin
> >
> > On Wed, Feb 27, 2019 at 9:06 PM Sheng Zha <zh...@apache.org> wrote:
> >
> > > MXNet follows semantic versioning so we will be able to delete them in
> > the
> > > next major release.
> > >
> > > -sz
> > >
> > > On Wed, Feb 27, 2019 at 8:53 PM Lin Yuan <ap...@gmail.com> wrote:
> > >
> > > > Dear Community,
> > > >
> > > > In MXNet there are many legacy operators such as this
> > > > <
> > > >
> > >
> >
> http://mxnet.incubator.apache.org/versions/master/api/python/symbol/symbol.html?highlight=convolution_v1#mxnet.symbol.Convolution_v1
> > > > >
> > > > that has been marked DEPRECATE for several releases. However, these
> > > > operators still exist in our code. This caused a few problems:
> > > >
> > > > 1) Make the codebase bloated and reduce readability
> > > > 2) Increase unnecessary maintanence effort
> > > > 3) Bug prone as some people will look up these legacy code as example
> > > > 4) Cause confusion to end users and make documentation page lengthy
> > > >
> > > > I would like to propose the following process (if there is no
> existing
> > > one)
> > > > to remove deprecate operators from our code base.
> > > >
> > > > 1. Documnent the deprecate operators/environment variables in the
> > release
> > > > note as well as man pages.
> > > > 2. Limit the life cycle of deprecate operators/argument to two minor
> > > > release. For example, if one operator is marked deprecate in 1.4
> > release,
> > > > it will be removed in 1.6 release.
> > > > 3. If there is some concern raised from customers during 1.4 and 1.5
> > > > release, we can convert the deprecated operator back to current and
> it
> > > will
> > > > be treated as new operator.
> > > > 4. PRs that remove deprecate operators should contain [Cleanup] in
> > title.
> > > >
> > > > Any comment is appreciated.
> > > >
> > > > Lin
> > > >
> > >
> >
>
Re: [DISCUSS] Process to remove deprecated operators
Posted by Junru Shao <ju...@gmail.com>.
Hi Lin,
I would love to share some immature ideas about deprecating operators. Not
only adopting semantic versioning, but also should we provide enough
informative error message for customers to understand how to replace
deprecated operators with new ones.
Thanks,
Junru
On Wed, Feb 27, 2019 at 9:30 PM Lin Yuan <ap...@gmail.com> wrote:
> Sheng,
>
> Thanks for your quick response.
> If that's the case, we will wait till 2.0 release to remove the deprecated
> operators from code.
>
> Best,
> Lin
>
> On Wed, Feb 27, 2019 at 9:06 PM Sheng Zha <zh...@apache.org> wrote:
>
> > MXNet follows semantic versioning so we will be able to delete them in
> the
> > next major release.
> >
> > -sz
> >
> > On Wed, Feb 27, 2019 at 8:53 PM Lin Yuan <ap...@gmail.com> wrote:
> >
> > > Dear Community,
> > >
> > > In MXNet there are many legacy operators such as this
> > > <
> > >
> >
> http://mxnet.incubator.apache.org/versions/master/api/python/symbol/symbol.html?highlight=convolution_v1#mxnet.symbol.Convolution_v1
> > > >
> > > that has been marked DEPRECATE for several releases. However, these
> > > operators still exist in our code. This caused a few problems:
> > >
> > > 1) Make the codebase bloated and reduce readability
> > > 2) Increase unnecessary maintanence effort
> > > 3) Bug prone as some people will look up these legacy code as example
> > > 4) Cause confusion to end users and make documentation page lengthy
> > >
> > > I would like to propose the following process (if there is no existing
> > one)
> > > to remove deprecate operators from our code base.
> > >
> > > 1. Documnent the deprecate operators/environment variables in the
> release
> > > note as well as man pages.
> > > 2. Limit the life cycle of deprecate operators/argument to two minor
> > > release. For example, if one operator is marked deprecate in 1.4
> release,
> > > it will be removed in 1.6 release.
> > > 3. If there is some concern raised from customers during 1.4 and 1.5
> > > release, we can convert the deprecated operator back to current and it
> > will
> > > be treated as new operator.
> > > 4. PRs that remove deprecate operators should contain [Cleanup] in
> title.
> > >
> > > Any comment is appreciated.
> > >
> > > Lin
> > >
> >
>
Re: [DISCUSS] Process to remove deprecated operators
Posted by Lin Yuan <ap...@gmail.com>.
Sheng,
Thanks for your quick response.
If that's the case, we will wait till 2.0 release to remove the deprecated
operators from code.
Best,
Lin
On Wed, Feb 27, 2019 at 9:06 PM Sheng Zha <zh...@apache.org> wrote:
> MXNet follows semantic versioning so we will be able to delete them in the
> next major release.
>
> -sz
>
> On Wed, Feb 27, 2019 at 8:53 PM Lin Yuan <ap...@gmail.com> wrote:
>
> > Dear Community,
> >
> > In MXNet there are many legacy operators such as this
> > <
> >
> http://mxnet.incubator.apache.org/versions/master/api/python/symbol/symbol.html?highlight=convolution_v1#mxnet.symbol.Convolution_v1
> > >
> > that has been marked DEPRECATE for several releases. However, these
> > operators still exist in our code. This caused a few problems:
> >
> > 1) Make the codebase bloated and reduce readability
> > 2) Increase unnecessary maintanence effort
> > 3) Bug prone as some people will look up these legacy code as example
> > 4) Cause confusion to end users and make documentation page lengthy
> >
> > I would like to propose the following process (if there is no existing
> one)
> > to remove deprecate operators from our code base.
> >
> > 1. Documnent the deprecate operators/environment variables in the release
> > note as well as man pages.
> > 2. Limit the life cycle of deprecate operators/argument to two minor
> > release. For example, if one operator is marked deprecate in 1.4 release,
> > it will be removed in 1.6 release.
> > 3. If there is some concern raised from customers during 1.4 and 1.5
> > release, we can convert the deprecated operator back to current and it
> will
> > be treated as new operator.
> > 4. PRs that remove deprecate operators should contain [Cleanup] in title.
> >
> > Any comment is appreciated.
> >
> > Lin
> >
>
Re: [DISCUSS] Process to remove deprecated operators
Posted by Sheng Zha <zh...@apache.org>.
MXNet follows semantic versioning so we will be able to delete them in the
next major release.
-sz
On Wed, Feb 27, 2019 at 8:53 PM Lin Yuan <ap...@gmail.com> wrote:
> Dear Community,
>
> In MXNet there are many legacy operators such as this
> <
> http://mxnet.incubator.apache.org/versions/master/api/python/symbol/symbol.html?highlight=convolution_v1#mxnet.symbol.Convolution_v1
> >
> that has been marked DEPRECATE for several releases. However, these
> operators still exist in our code. This caused a few problems:
>
> 1) Make the codebase bloated and reduce readability
> 2) Increase unnecessary maintanence effort
> 3) Bug prone as some people will look up these legacy code as example
> 4) Cause confusion to end users and make documentation page lengthy
>
> I would like to propose the following process (if there is no existing one)
> to remove deprecate operators from our code base.
>
> 1. Documnent the deprecate operators/environment variables in the release
> note as well as man pages.
> 2. Limit the life cycle of deprecate operators/argument to two minor
> release. For example, if one operator is marked deprecate in 1.4 release,
> it will be removed in 1.6 release.
> 3. If there is some concern raised from customers during 1.4 and 1.5
> release, we can convert the deprecated operator back to current and it will
> be treated as new operator.
> 4. PRs that remove deprecate operators should contain [Cleanup] in title.
>
> Any comment is appreciated.
>
> Lin
>