It strikes me that both moving to Python3 and dropping Genshi in 1.5 makes a whole lot of sense. No need to try to make all the Genshi things knocking around work with Python 3 (presuming there's even an official Python3 compatible Genshi release by that time) . Anything with Genshi dependencies has a hard ceiling of Trac 1.4. Makes things very clear. -JL
On Monday, June 4, 2018 at 10:37:39 PM UTC-5, RjOllos wrote: > > > > 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] <javascript:> 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.
