On Thu, Sep 06, 2018 at 09:25:45PM +0800, Qu Wenruo wrote: > > The deprecation should be done in a few steps. First issue a warning > > that the feature is deprecated and will be removed in release X. Then > > wait until somebody complains (or not) and remove the code in release X. > > > > The X is something like 4.22, ie. at least 2 cycles after the > > deprecation warning is added. > > Thanks for the deprecation progress. > > However I'm wondering if the "release X" is really needed in the warning > message.
The specific version or date is IMHO a good practice. For features known to be used the deprecation period may be years long and hard to predict the version. In case of the qgroup inheritance it's a minor feature set reduction and the 2 release period is there just in case. We can be specific here and we should put that into the message. > (I may forgot to submit the real deprecation patch for that release). I document the feature deprecation and removal on the wiki changelog, so if you forget, slipping one release causes no harm but I think somebody will notice in time.
