I agree that reading the whole document gave some hints about the incoming troubles, but I guess many people (like me), on first pass, just thought "OK that's all I wanted to hear" and went by. Plus, it's a little like saying "this dogs doesn't bite", and then later "if the dogs wants to bite you, it barks first" - disturbing at least. ^^
My bad, if people are guaranteed 2 x 24-month cycles before a feature gets removed, it's already much better. However, the same pattern as previously appears in docs : "each feature release will continue to have a few documented backwards incompatibilities where a deprecation path isn’t possible or not worth the cost.". I might be paranoid, but I foresee lots of dependency breakages in the future, if incompatibilities continue to be introduced at developer's will.... History proved even seemingly harmless django modifications (ex. import aliases removed) broke external code, sometimes forcing "commit reverts" in django code. The idea of DCP is not to prevent ANY code removal (in particular when it deals with django settings, that any project can always update), but rather to allow very, very long-term compatibility, for trivial modifications like renames and signature changes ; that being said, even import proxies (white magic with meta importers, to keep alive modules like django.contrib.comments) seem to work quite well, hassle-free. Concerning django unit-tests, here is the question : the version XXXX of django, how can one prove that it really is backwards compatible with the branch/version YYYY (except for a few documented breakages) ? Correct me if I'm wrong, but currently I see no automated way to check that, so an unwanted regression is always possible ; if "warnings" aspects are removed from tests, this becomes possible. I dunno which such regression happened by the past, if they did, (this would require deep-browsing the Git repo), but it's a point of weakness of the backwards compatibility commitment imho, as *any* untested commitment is. On a side note, this mixing of concerns prevents me, for example, from testing that LatestDjango+DCP is well compatible with previous versions of django (since warnings, at least, differ). regards, Pascal 2017-01-12 17:20 GMT+01:00 Tim Graham <timogra...@gmail.com>: > > "*Django promises API stability and forwards-compatibility since > version 1.0. In a nutshell, this means that code you develop against a > version of Django will continue to work with future releases*." were imho > untrue. > > Perhaps the API stability statements are too strong and need some > clarification, but please don't quote without reading the rest of the > document, e.g. "If, for some reason, an API declared stable must be removed > or replaced, it will be declared deprecated but will remain in the API for > at least two feature releases. Warnings will be issued when the deprecated > method is called." > > > If I understand correctly, with the new release process, reusable apps > and libraries would still be broken every two LTS releases, i.e every 16 > months. > > Yes, they may break if they aren't updated, although LTS releases are > every 24 months. > > My understanding of your proposal is that Django never removes deprecated > features but rather moves them to a "compatibility" library. Removing > deprecated features helps simplify things. I believe that prohibiting code > to be removed from Django would be a significant overhead in complexity and > be a drag on the ability to evolve the framework. > > About testing, can you give an example of a problem that wasn't detected > by our current approach? I'm unsure what problem your suggestions are > trying to solve. > > On Thursday, January 12, 2017 at 10:39:54 AM UTC-5, Pkl wrote: >> >> >> Hello, >> >> thanks for your feedback, >> >> Actually this DCP layer is mainly aimed at backwards compatibility of >> dependencies : running, on the latest version of django (with maximal >> security bugfixes), older reusable apps which are incompatible with >> each-other, or with said latest version of Django. >> >> When I hear "*lax semantic versioning*", it makes me think about an >> "almost alive parrot" or a "mostly non-lethal drink", i.e not something >> especially reassuring ; especially when I remember how the sentences "*Django >> promises API stability and forwards-compatibility since version 1.0. In a >> nutshell, this means that code you develop against a version of Django will >> continue to work with future releases*." were imho untrue. >> >> If I understand correctly, with the new release process, reusable apps >> and libraries would still be broken every two LTS releases, i.e every 16 >> months. For a big software ecosystem, this is still a really short >> lifespan. And since not every developers cares about deprecation warnings >> (when they are visible), it means any pypi package for django which hasn't >> been updated for 6 or 12 months would quite likely be broken. This means >> lots of forks without any added value, without evolutions nor bugfixes, >> just "so that it keeps working" . >> >> Many major languages or frameworks have strong commitments on >> retrocompatibility, and have succeeded on this commitment for years >> (python2 being one of them) ; I remember a blogpost where a Qt developer >> explained at great lengths how they carefully crafted every function >> signature, so that it could evolve without breaking older code. If they can >> achieve this C++, how comes major python frameworks would do less ? >> >> My opinion is that the "walk or die" approach of Django is harmful to its >> ecosystem, and furthermore unnecessary, since a layer like DCP can ensure >> BOTH a wart-free & fast-moving codebase, and a strong retrocompatibility. >> >> About the current tests of deprecation warnings, to me this is a wrong >> "separation of concerns". Checking that a web framework feature works, and >> checking that it properly triggers specific warnings, are aspects which >> should not be mixed with each other. >> Why ? Because it prevents advanced uses of test suites. For example, how >> do you check that Django version X.Y hasn't broken code written for >> previous releases ? Just because it passes its own test suite ? Just >> because "committers have been careful" ? I don't think it says much. What >> I'd do, is rather run the unit-tests of the previous django version >> (excluding some specifically marked "short-lived" tests), against the >> newest code. This would mean so much more. >> >> Here is my view on why using a compatibility layer in Django (or any >> framework, actually) would be a good idea : >> >> PROs: >> - cleaner django codebase >> - less work to deprecate features >> - automated checks of compatibility between django version >> - easily achieve long-term compatibility >> - more control given to django users regarding compatibility choices >> >> CONs: >> - small additional delay at django startup ? >> >> Am I missing something there ? >> >> regards, >> Pascal Chambon >> >> Le mardi 10 janvier 2017 01:29:41 UTC+1, Tim Graham a écrit : >>> >>> Our new deprecation policy was designed to eliminate the need for this >>> type of compatibility library. If you want to support more Django versions >>> than what our guidelines recommend (which may involve supporting versions >>> that no longer receive security updates), I guess this library could be >>> useful, but I wouldn't give it an endorsement in the Django docs. >>> >>> Perhaps you could elaborate on "Most importantly, this way, django main >>> tests suites would stop making asserts on the presence or absence of >>> deprecation warnings (which is a way of mixing unrelated aspects of the >>> framework)." I don't understand your complaint about the current way we're >>> testing deprecation warnings. >>> >>> On Saturday, January 7, 2017 at 3:17:06 PM UTC-5, Pkl wrote: >>>> >>>> >>>> Hello, >>>> >>>> I've *at last* had some time to experiment with the idea I had thrown >>>> years again, of a system to workaround the recurring breakages introduced >>>> by new django releases, breakages which sometimes lead to unreconcilable >>>> requirements between django apps. >>>> >>>> After a sprint at PyconFR, with a colleague (R. Gomès), and some >>>> cleanups and improvements, here it is: >>>> >>>> https://github.com/pakal/django-compat-patcher (also known as DCP) >>>> https://pypi.python.org/pypi/django-compat-patcher >>>> >>>> The philosophy of the module is that, with extremly agile languages >>>> such as python, one doesn't have to choose between a fast-moving project, >>>> and a compatibility-friendly project. >>>> So, in an approach reminding "aspect oriented programming", DCP >>>> separates the Django codebase, which may move forward and be left mostly >>>> free of compatibility shims, from retrocompatibility shims ; and changing >>>> the "level of compatibility" of a project is just the matter of tweaking >>>> some Django settings. >>>> Since, as usual, "explicit is better than implicit", logging and code >>>> warnings are used to ensure that project users are informed about what >>>> compatibility fixers are applied, and how project dependencies are rated >>>> deprecation-wise. >>>> >>>> I've noticed there had been debates and evolutions for the past years, >>>> until the switch to a "lax semantic versioning" for Django. >>>> Surely it's an effort in the right direction, but I guess I'm not the >>>> only one worried by the "lax" adjective ; especially after the long history >>>> of breakages occurring for quite cosmetic reasons (eg. the removal of >>>> urlpatterns(), which broke most django apps available, whereas dotted-path >>>> URLs were rather harmless). >>>> That's why I think DCP is still relevant, as it gives back some control >>>> over compatibility to end users of Django ; and it should remove part of >>>> the apprehension some may have known too, when installing a new Django >>>> version. >>>> >>>> DCP has been successfully used to upgrade wide projects from django 1.7 >>>> to django 1.10, with no hassle. But more feedback would be nice, before it >>>> can be marked "production ready". >>>> The project welcomes patches, especially new backward/forward >>>> compatibility fixers one might need. >>>> >>>> >>>> *Apart from that *: I think many people could benefit from more >>>> instructions about how to handle (backwards and forwards) compatibility, so >>>> here are some ideas I had : >>>> >>>> >>>> *1) Advertising compatibility systems for Django, in the official docs.* >>>> >>>> That is to say, packages like "django-compat" (which I only discovered >>>> lately), dedicated to library developers who need a wide compatibility. >>>> And packages like "django-compat-patcher" for project maintainers who >>>> have compatibility issues and deadlines (it's not *always* the right moment >>>> to fork and patch a bunch of big dependencies). >>>> All that would come in addition to the docs now mentioning "how to >>>> support 2 LTS versions at a time". >>>> These measures might diminish the number of django app using handmade >>>> compatibility shims, or completely ignoring previous versions of django. >>>> >>>> >>>> *2) Pushing a compatibility system like DCP into Django itself* >>>> >>>> What would be the gain ? It would pleasantly reduce the work needed for >>>> Django evolutions. >>>> >>>> At the moment, first compatibility shims must be introduced, and >>>> specifically tested in code ; then these compatibility shims must be >>>> removed, and their tests with them. >>>> >>>> With a separate compatibility system, only half the work would be >>>> needed : once the code has been modified, the old version is moved to a >>>> fixer, and its associated unit-test is moved to the compatibility system >>>> test suite. >>>> The activation/deactivation of this particular fixer is then only a >>>> matter of django settings, not of new code commits. >>>> Most importantly, this way, django main tests suites would stop making >>>> asserts on the presence or absence of deprecation warnings (which is a way >>>> of mixing unrelated aspects of the framework). Django tests suites could >>>> thus be leveraged by compatibility systems to ensure that the whole system >>>> is well sane and backwards/forward compatible, whatever the series of >>>> django shims applied. >>>> >>>> >>>> *Any remarks about DCP concept itself, or about suggestions for >>>> doc/core inclusions ?* >>>> >>>> thanks, >>>> regards, >>>> Pascal >>>> >>>> -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/django-developers/dKeLB-qR7lY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/b5b58695-2e5c-49f2-86b9- > 63c64f44bc99%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/b5b58695-2e5c-49f2-86b9-63c64f44bc99%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BXNUS0RfWLja7%3Db3vhyxVcsBzC_VOaYy9Hf3j%3DBUCgAFGC_gQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
