Update django requirement from >=2.2.9,~=2.2 to >=2.2,<4.0

[dependabot-preview]

Updates the requirements on django to permit the latest version.

Commits

• c2250cf [3.0.x] Bumped version for 3.0.4 release.
• 26a5cf8 [3.0.x] Fixed CVE-2020-9402 -- Properly escaped tolerance parameter in GIS fu...
• c5cfaad [3.0.x] Fixed #31150 -- Included subqueries that reference related fields in ...
• 4977f20 [3.0.x] Documented default value of InlineModelAdmin.extra.
• 5320ba9 [3.0.x] Removed outdated note about not supporting partial indexes by Django.
• 94e192a [3.0.x] Refs #31312 -- Fixed FTimeDeltaTests.test_date_case_subtraction() test.
• 16cacdc [3.0.x] Fixed #31312 -- Properly ordered temporal subtraction params on MySQL.
• 59ac25c [3.0.x] Fixed #31313 -- Fixed is_upperclass() example in enumeration types docs.
• ae6c6f9 [3.0.x] Removed hint from fields.E310 message in system check docs.
• 0193a16 [3.0.x] Fixed #31303 -- Removed outdated note about symmetrical intermediate ...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Note: This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit.

You can always request more updates by clicking Bump now in your Dependabot dashboard.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

[codecov]

Codecov Report

Merging #219 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #219   +/-   ##
=======================================
  Coverage   87.15%   87.15%           
=======================================
  Files          42       42           
  Lines        1892     1892           
=======================================
  Hits         1649     1649           
  Misses        243      243

Flag	Coverage Δ
#unittests	87.15% <ø> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 98adbb2...924ef00. Read the comment docs.

[CasperWA]

Adding the patch to the minimum required django version.

For the same reasons as was the case for #218, this change makes sense.

However, it should be noted, that for fresh installations, the newest allowed version will be installed by default (i.e., django v3.0.4).

New developments

[CasperWA]

It seems to me we should be careful.
At the moment now, we are not testing the oldest versions of django and elasticsearch-dsl that we "support".

We could remedy this, I believe, by setting the requirements.txt to the oldest versions we support, as long as it does not span more than two major versions of a dependency, and consequently have the docker_image CI test check the oldest supported versions - although it is only a validator test, not a proper test of the transformers - the tests that actually matter...

TL;DR: We may not properly test our package for the support we claim with these dependencies spanning multiple major versions.

[ml-evs]

TL;DR: We may not properly test our package for the support we claim with these dependencies spanning multiple major versions.

I agree that we should be more cautious here, given that we don't really have any tests for elasticsearch/Django directly and instead are only testing the transformers.

[CasperWA]

TL;DR: We may not properly test our package for the support we claim with these dependencies spanning multiple major versions.

I agree that we should be more cautious here, given that we don't really have any tests for elasticsearch/Django directly and instead are only testing the transformers.

So the question then becomes whether we should stick to the version of the implementation at the time or move to a newer one?

[markus1978]

At least for elasticsearch_dsl, the underlying question is, would it work with both versions? I imagine that the python interface is the same for v6 and v7 and all differences between the versions are in the elastic search request/response handling. In this case we can span over both versions. If not, we might need different version specific transformers.

It seems to work for 7.1.0 which you have in the requirements, right? I can tell you it also works (at least we use it) for 6.4.0 (selected by pip from elasticsearch-dsl>=6.0.0,<7.0.0). Therefore, I think it should work for elasticsearch-dsl>=6.0.0,<8.0.0 as well. I would not bother to support older versions.

[CasperWA]

At least for elasticsearch_dsl, the underlying question is, would it work with both versions? I imagine that the python interface is the same for v6 and v7 and all differences between the versions are in the elastic search request/response handling. In this case we can span over both versions. If not, we might need different version specific transformers.

It seems to work for 7.1.0 which you have in the requirements, right? I can tell you it also works (at least we use it) for 6.4.0 (selected by pip from elasticsearch-dsl>=6.0.0,<7.0.0). Therefore, I think it should work for elasticsearch-dsl>=6.0.0,<8.0.0 as well. I would not bother to support older versions.

Yeah, we just updated from elasticsearch-dsl~=6.4, i.e., >=6.4.0,<7.0.0 to the current span over both v6 and v7.
We will keep it this way then, but eventually only test v7.1.0 (since this is what's installed in the CI tests). Is that acceptable?

[markus1978]

Sounds good to me.

…

On Tue, Mar 10, 2020 at 12:24 PM Casper Welzel Andersen < ***@***.***> wrote: At least for elasticsearch_dsl, the underlying question is, would it work with both versions? I imagine that the python interface is the same for v6 and v7 and all differences between the versions are in the elastic search request/response handling. In this case we can span over both versions. If not, we might need different version specific transformers. It seems to work for 7.1.0 which you have in the requirements, right? I can tell you it also works (at least we use it) for 6.4.0 (selected by pip from elasticsearch-dsl>=6.0.0,<7.0.0). Therefore, I think it should work for elasticsearch-dsl>=6.0.0,<8.0.0 as well. I would not bother to support older versions. Yeah, we just updated from elasticsearch-dsl~=6.4, i.e., >=6.4.0,<7.0.0 to the current span over both v6 and v7. We will keep it this way then, but eventually only test v7.1.0 (since this is what's installed in the CI tests). Is that acceptable? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#219?email_source=notifications&email_token=AA2WUXFVEEMAWX22TW5D3RTRGYPPHA5CNFSM4LELMIS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOLAXGQ#issuecomment-597035930>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2WUXCD7I4B3UOFO7VFQMDRGYPPHANCNFSM4LELMISQ> .

[ml-evs]

This looks good to me now too.