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 <wenyang....@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 <chai.ba...@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 <apefor...@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 <junrushao1...@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 <apefor...@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 <zhash...@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 <apefor...@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/> > > >
