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 <anirudhk...@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 <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/> > > > > > >
