Abhilash Raj writes:
> True, we define the supported Django versions explicitly in tox.ini, one
> per minor version. Sometimes, it gets out of date.
I don't have a problem with "sometimes". But the current situation
looks unprofessional.
> > Also, the envlist for Postorius is just unuseful. Django-1.1.1? LOL
>
> 1.1.1 is probably a typo for 1.11 I think.
Sure, but still, Django 1?!
> > What I think we should do is
> >
> > 1. Put a full list of Django versions that we have ever supported in
> > the deps variable.
>
> By ever supported, you mean even the ones we don't support anymore?
Yes. We could put in a comment that they're not necessarily supported
by us, but there are always going to be people (RHEL...) who for
whatever reason want to be a couple versions behind what we support.
This would also go forward with versions that are still experimental.
The logic behind "ever supported" is that it's an easy rule to update
to (just take the union of the version specs in various files), and we
only do it once. After that, we only add "djangoXX: Django >=x.y,
<x.y", we never delete them. We never have to make a decision that
Django 1.11 is not just unsupported, but we're going to erase it.
Once a version falls out of envlist (or whatever the ground source of
truth for "supported" is), you're 100% on your own, we're not even
going to tell you "sorry, that's Python 2 only and we don't do Python
2". But if somebody wants to run tests against Django 1.11, don't
make them dig up the version spec that we already know. Ditto if
somebody is running against Python:main, we put that in there and
people can use it (although I hope nobody puts that in envlist! :-)
> > > 2. Put the full list of Python-Django combinations that are supported
> > (where Django is relevant).
>
> Put that where? In envlist?
Yes.
> > 3. Standardize on lint for syntax checking and cov for coverage analysis.
>
> Agreed!
Good!
> > Then people with a single version of Python and a single version of
> > Django (which I think is going to be typical of non-core-developers
> > including a lot of people who send patches) can just run "tox".
>
> So, you suggest we put a single environment in envlist, something like:
>
> envlist = "py39-django31"
No, that's not the way envlist works. I'm saying we put
envlist = py{36,37,38,39}-Django{22,23,30,31}
(which expands to 16 combinations!) and somebody who only has Python
3.8 and Django 2.3 installed will only get that combination tested.
... Hm, on second thought I'm not sure if tox works that way for
anything but "pyXX" by default, but I'm pretty sure we can tell tox
only to test installed versions of Django, and not download them if
they're not already installed.
> I have almost stopped running the full CI locally and just relying on CI
> to run other version jobs if one passes locally.
Well, you could always vendor your tox.ini. ;-) I don't really object
to just putting one version into envlist, but if we get into a
situation where some people are working on compatibility the most
recent Python while others are using something a couple of releases
back, it could get annoying.
> When you say "top page on Gitlab", do you mean something like:
>
> https://gitlab.com/mailman
This one.
> The former doesn't have any customizations we can do, no "group"
> level README available.
That kinda sucks. It is possible to create subgroups (I guess
"archived" is a special-purpose subgroup available by default). Not
sure it's worth the effort. Too many things to keep synced!
> But we can add this to Core's landing page within the README.rst.
That might be best. Or maybe just rely on readthedocs.
Steve
_______________________________________________
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9
