On Friday, June 9, 2017 at 6:43:13 PM UTC-7, RjOllos wrote: > > > > On Tuesday, January 17, 2017 at 11:05:02 AM UTC-8, RjOllos wrote: >> >> >> >> On Tuesday, January 17, 2017 at 8:08:59 AM UTC-8, cboos wrote: >>> >>> Hello, >>> >>> On 12/30/2016 1:07 AM, [email protected] wrote: >>> > I may be jumping the gun a bit as a 1.3.2 (jinga2) tag hasn't been >>> > declared yet, but what is the state of the python3 support progress? >>> >>> On this topic... >>> >>> I've just seen the following from Python-announce, it's probably not the >>> first time they say it, but it's the first time I pay attention: >>> >>> > Python 3.4 is now in "security fixes only" mode. This is the final >>> stage of support for Python 3.4. Python 3.4 now only receives security >>> fixes, not bug fixes, and Python 3.4 releases are source code only--no >>> more official binary installers will be produced. >>> >>> It's great that we can now focus on using only Python 2.7 for trunk, and >>> though I'd love to be able to continue to have only that version in >>> mind, I see that the interest for supporting Python 3.x is there, so I >>> won't stand in the way, and maybe even help out a bit... >>> >>> But I don't want to have to take into account more quirks than necessary >>> by supporting already deprecated 3.x versions. So can we please forget >>> about 3.4 support, at the very least? >>> >>> Supporting 3.5 and 3.6 will "only" triple the maintenance cost for >>> running tests and the risks of hitting bugs and quirks specific to this >>> or that Python version (we already were there). Personally I'll focus on >>> 3.5, I think. >>> >>> So here's my strong vote for supporting only Python 3.5 and 3.6 for Trac >>> 1.3.2, let's forget about the earlier 3.x versions. >>> >>> -- Christian >>> >>> P.S: and Ian, it's Jinja2, not jinga2 (nor ginsha ;-) ) >>> >> >> I fully agree with only supporting Python 3.5 and 3.6, along with Python >> 2.7. >> >> My motivation for moving to Python 3.x is similar to your motivation for >> not supporting Python 3.4 and earlier. Python 2.7 is in maintenance mode >> and won't be supported beyond 2020. Eventually we'll need a plan for moving >> off Python 2.7, and having a pathway to 3.x sooner rather than later will >> be better for the project. >> >> I've been working on rebasing Jun's python3 branch (#12130) for the past >> week. The tests are passing on Python 2 and I have 6 more errors to fix on >> Python 3.6. I'll make the branch public soon since I expect there is a lot >> more work to do, including code review. >> >> - Ryan >> > > > I think it's worth considering to just do a switch to Python 3.5+ in Trac > 1.5.1 rather than supporting 2.7 and 3.5+. > * Python 2.7 is end-of-life in 2020 (PEP:0373) > * Optimistically, Trac 1.6 would be July 2018 > * We could continue to support Trac 1.4.x through 2020 > * Targeting fewer python versions can increase development velocity on the > trunk > * We can take advantage of the improvements in Python3 without concern for > a six compatibility layer > * Backward compatibility for old python versions will likely continue to > be less important with the adoptions of containers and other isolated > environments > > I would like to look to the future, improve my proficiency in the latest > versions of Python focus and focus on adding features. It feels like we've > had an excessive focus on the past (e.g. active development supporting > Python 2.5 continues for Trac 1.0-stable) and I think it hinders the > project. I can think of some counterpoints, I just don't think any of them > are as important as the points I've listed. Django is dropping support for > Python2 in the next major release (1). > > Are there any arguments for needing to continue to have the latest stable > release run on Python 2.7 in mid-to-late 2018? It would seem to me that > anyone wanting to stay with the latest Trac can spend the next 12-18 months > on their migration plan for this tiny web app. > > - Ryan > > (1) https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ >
Tim has pushed some patches to move us towards Python3, so I'm raising this topic again for discussion. I still favor switching to Python3 in a 1.5.x release and supporting Trac 1.4-stable through 2020. The Python foundation is no longer supporting Python 2.7 on Jan 1st, 2020. Tim proposed using "six" to keep all the tests passing on a branch while migrating to Python3. Presumably we would just discard those changesets to drop Python 2.7 support, if we are to go with a branch supporting Python 3.5+. It seems like there are options other than the six module. I've seen a fair bit of discussion about "future" lately: https://pypi.org/project/future/ I'm also hoping to do some work on git-svn mirroring this summer so that we have the option of committing directly to Git, and perhaps directly to a Git repository on GitHub. One or both of those changes make it easier to push staged changes. - Ryan -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
