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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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/>
