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, i...@iprcom.com 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 trac-dev+unsubscr...@googlegroups.com. To post to this group, send email to trac-dev@googlegroups.com. Visit this group at https://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
