For me, as an extensive django user, a whole deprecation thing is somewhat useless and confusing. I'd prefer deprecated elements were just removed. Then when I upgrade django I'll just upgrade it and fix any wrong calls, imports, monkey patches etc. Proper upgrading docs, which you write anyway, will make it into a couple of days. The way it is done now still requires that two days but also make me think about separate deprecation concept, about what part of django is public and what is not cause they have separate deprecation policies. It also encourages me to slack at upgrading and use something deprecated for a while longer.
On 2 окт, 00:10, Luke Plant <l.plant...@cantab.net> wrote: > Hi all, > > The Django deprecation timeline [1] is very inconsistent in its usage of > the terminology 'deprecated'. For example, the 1.5 section often says > "is deprecated" or "has been deprecated", when what they mean is "will > be removed", which is what the other sections generally tend to say. > Some in section 1.6 say a feature "will be deprecated". > > Can we have a consistent policy on this terminology? > > Miriam-Webster: > > "deprecate: to express disapproval of" > > So something is 'deprecated' as soon as we say we are going to remove it > - we are expressing disapproval, but allowing it to continue > temporarily. The confusing thing from Python terminology is that we then > add PendingDeprecationWarning, followed by DeprecationWarning, which > suggest that deprecation is something that will happen in the *future*, > the thing that happens when we finally remove it. But that isn't normal > English usage, and we can't sensibly use 'deprecated' for both the > beginning and the end of the process. > > So I'd suggest that we stick to: > > - deprecated = the first time we say we are going to remove it, > and normally means we add PendingDeprecationWarning > > - removed - when we actually remove. > > In the deprecation timeline, we can simply say "X will be removed", or > "X will be removed in favour of Y". If it is outside the normal > deprecation policy in some way, we can mention that, otherwise no need > to say which version it was deprecated in. In our release notes, we > carry on announcing deprecation as we are doing now. The only problem is > that our 'deprecation timeline' effectively becomes a 'removal > timeline', but I think it will be clear enough if the rest of our > terminology is. > > Comments? > > Luke > > [1]https://docs.djangoproject.com/en/dev/internals/deprecation/ > -- > "It is a truth universally acknowledged, that a single man in > possession of a good fortune, must be in want of a wife." (Jane > Austen) > > Luke Plant ||http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
