On Friday 27 September 2013 20:01:00 Carl Meyer wrote: > > 1) The status quo. If people run the new "manage.py check" command, > they'll get a warning directing them to the release notes. But given > that "manage.py check" is new, its unlikely anyone would run it unless > they've already read the release notes, so this isn't worth much. > > 2) The new test runner issues some kind of warning unconditionally on > 1.6 (this seems to be what you're proposing). That would certainly catch > the people we need to catch, but it seems like an awfully big hammer. > Once you know about the new test runner and have adjusted your tests, > wouldn't it be irritating to keep seeing that warning every single time? > And people creating new 1.6 projects would be irritated too, since the > warning is useless to them. > > 3) A first-run warning that can be turned off (and presumably would be > off by default in new projects). The obvious mechanism for turning it > off would be something in settings. That either means introducing a new > setting specifically for this warning, or warning anybody who doesn't > have an explicit TEST_RUNNER override (meaning all 1.6 projects would be > required to needlessly specify the new test runner in their settings in > order to silence the warning.) > > 4) A variant of (3) where we introduce a more general setting that we > can use for similar situations in the future. Something like a > SILENCE_UPGRADE_WARNINGS setting that's a list or set of well-known > strings, or something: SILENCE_UPGRADE_WARNINGS = ['discovery-runner'] > or some such. > > 5) The new test runner, every time its run, goes out and looks for tests > in the locations where the new runner won't find them (models.py files, > app tests/__init__.py files, tests.py in INSTALLED_APPS that are not > within the CWD, doctests) and warns you if it finds any. This would be a > fair chunk of code that would be easy to get wrong, and I think it's > really too late to add it to 1.6. It would also slow down test-running > unnecessarily on every run. > > So, like I said, a bunch of bad options. Which is the least bad? > Personally I'd be open to considering (1), (3), or (4). Interested in > others' thoughts. > I think in view of the GSoC work and the check command, (4) as phrased above would be mostly duplication of effort. The 'check' command, IIRC, already includes mechanisms to silence specific warnings.
I think my preferred solution is a mix of your (3) and (5) -- a search for tests that can be turned off. I think (though I'm not too familiar with that area of the code) that the coding here is not too hard -- essentially, run the old code as well as the new code for building the test-suite, and diff the results. Another idea is a variation on your (4) -- add a setting to specify the Django version expected by the project; so if a project says, for example, DJANGO_USED="1.5", we emit suitable upgrade warnings. This may have a problem -- it may create unwarranted expectations of backward- compatibility support; people may think it tells newer Django versions to use the behavior of older versions, rather than warn on breaking changes. But I do find it has a certain appeal -- it's a lot like including the protocol version in messages. My 2 cents, Shai. -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
