Do you think the proposal is not in compliance? There is no requirement that we drop anything more than 42 months old, it is just recommended. The change in the Python release cycle has created some difficulty. With the yearly cycle, 4 python yearly releases will cover 3-4 years, which seems reasonable and we can probably drop to 3 releases towards the end, but with 3.7 coming 18 months after 3.6, four releases is on the long side, and three releases on the short side, so keeping 3.6 is the conservative choice. Once the yearly cycle sets in I think we will be fine.
Chuck
I believe that it really helps to "lead by example".
I don't mean to reference threads that you have all participated in, but the discussion in:
Makes it clear to me at least, that downstream will follow the example that numpy sets.
At the time of writing, it was anticipated that Python 3.7, 3.8, and maybe 3.9 would exist in Nov 1st.
suggests that any release July 23 should only support 3.7.
Barring COVID delays, it seems natural that in Nov 2020, support for Python 3.6 be dropped or that the NEP be revised.
These decisions are hard, and take up alot of mental capacity, if the support window needs revisiting, that is fine, it just really helps to be able to point to a document (which is what NEP29 seemed to do).
The problem is that if we drop 3.6 the oldest version of Python will only be 30 months old, not 36. Dropping 3.6 for 1.20.x will make it 36 months, which is the recommended minimum coverage. I made sure that the language did not preclude longer support periods in any case.
It would be helpful here if more people would comment, I would be happy to go with the shorter period if a majority of downstream projects want to go that way. It's not that I love 3.6, but there is no compelling reason to drop it, as there was for 3.5, at least that I am aware of.
Chuck