Given that I rarely use this in practice, the potential advantages do not
weigh up aginst the actual disadvantages (breakage today, as well as in March,
see 38d49f5000)
Fix#168
'philosphofically' I prefer to keep my dev-deps in flux ('bleeding edge')
but since I barely use the DJDT I'd rather just pin it at a known-working
version.
Also: 6.0 introduces DB-models (for a debug tool) which I'm not a fan of.
Probably removing DJDT right after this, which would make this commit to
be a good point to revert to if we ever want to reintroduce it
See #168
the trade-off for reproducability/busywork is different for
development deps; for those bleeding edge is just fine, because
the bleeding will be by me and the consequences are minor.
And removing the pin removes some dependabot busywork
Trying to balance 'upgrade fatigue', 'stale deps' and 'being undefined'
With the present pattern:
* Only 'used by me' is defined; 'transitive dependencies' are left to upgrade.
* Dependabot is responsible for the major/minor updates; this will trigger
a PR & CI, and thus the required explicitness (but also: some work)
* Patch versions are assumed to be compatible, and are left to upgrade in the
background ('automatically')
