I believe now after the release of Lektor 3.2 it is time to drop support for Python 2, which has reached EOL on the first day of this year.
yagebu
All 5 comments
What's the best way to approach this? We still need to maintain 3.2.x for a while. Do we want to make master py2-free right away, or wait until 3.3 / 4.0... or?
xlotlu
on 16 Oct 2020
I think we should release 3.2.1 and then merge this. If we need to fix something for 3.2.x we create a new 3.2.x-maintenance branch and tag releases on that? When we release Lektor 4 (I guess we do a major bump?) we stop maintaining 3.2.
runfalk
on 16 Oct 2020
I think we should release 3.2.1 and then merge this. If we need to fix something for 3.2.x we create a new 3.2.x-maintenance branch and tag releases on that?
Ok. I was just thinking that after a severe py2-cleanup it might get difficult do backport some fixes.
When we release Lektor 4 (I guess we do a major bump?) we stop maintaining 3.2.
Or maybe stop maintaining at 3.3? To me Lektor 4 should happen if there are some serious architectural changes / compatibility breakage.
xlotlu
on 16 Oct 2020
That is true. I didn't really think about the backporting issue.
I mean removing Python 2.7 support is pretty major compatibility breakage I guess. Though it'd feel a bit silly releasing Lektor 4 and saying "We only removed Python 2.7 support".
runfalk
on 16 Oct 2020
What's the best way to approach this? We still need to maintain 3.2.x for a while. Do we want to make master py2-free right away, or wait until 3.3 / 4.0... or?
I'd be for making py2-free ASAP and creating a 3.2-maintenance branch where we do backports of just plain fixes. And if these backports stop being possible, I think it'd be fair to end support for 3.2.
I think it's somewhat overblown to worry so much about backward compatibility. Supporting Python 2 adds a lot of churn (I couldn't just fix the lint to see if the failing builds were due to actual lint/test failures). That time would be better spent on actual features and bug fixes IMHO. Right now I definitely feel hesitant to make any fixes and changes to the Python code due to this.
I don't have a strong opinion on the version number change and think that either would be fine. Technically, increasing the required Python version doesn't feel much different than upping any other dependency requirement.
yagebu
on 16 Oct 2020
Related issues
relikd
路
6Comments
geekpete
路
7Comments
item4
路
3Comments
Endogen
路
7Comments
nixjdm
路
7Comments
Most helpful comment
I'd be for making py2-free ASAP and creating a 3.2-maintenance branch where we do backports of just plain fixes. And if these backports stop being possible, I think it'd be fair to end support for 3.2.
I think it's somewhat overblown to worry so much about backward compatibility. Supporting Python 2 adds a lot of churn (I couldn't just fix the lint to see if the failing builds were due to actual lint/test failures). That time would be better spent on actual features and bug fixes IMHO. Right now I definitely feel hesitant to make any fixes and changes to the Python code due to this.
I don't have a strong opinion on the version number change and think that either would be fine. Technically, increasing the required Python version doesn't feel much different than upping any other dependency requirement.