0.12 was our last LTS release. I've proposed Trac 1.6 should support Python 3.5+. Given that, and the recent transition to Jinja2, I think it makes sense to have 1.4 be an LTS release that we support for the next several years.
Please share any thoughts.
That sounds like a good idea. I would further suggest renaming Trac 1.6 as Trac 2.0, considering the massive changes which would have been made: Python 3.5 and Jinja2.
On Tue, Aug 27, 2019 at 12:52 AM RjOllos <rjo...@gmail.com> wrote:
> The Roadmap (1) describes the release sequence.
> 0.12 was our last LTS release. I've proposed Trac 1.6 should support Python 3.5+. Given that, and the recent transition to Jinja2, I think it makes sense to have 1.4 be an LTS release that we support for the next several years.
Is it opportune to long term support a version that will only run on
Python 2.7, given the fact that the platform it runs on won't be
supported after January 1st 2020?
Additionally, you said you also proposed that Trac 1.6 should
_support_ python 3.5+, implying that it should also support python
Arguably, in today's deployment ecosystem, with containers and
virtual environments, it is not too much of a burden just to cleanly
switch to Python 3.5+ (and perhaps even to make it 3.7+, as Python 3.5
will cease to be supported after September 2019).
Now I realize that the switch to Python 3 will mean ending support for
all the plugins, but the opportunity in that is that all unmaintained
Trac Hacks can be archived, and that some major conceptual changes
(like TracMultiProject, and perhaps some integration of some of the
core tennets of the Trac Account Manager) can be implemented.
Just some input from a long-time Trac user and sometimes plugin
developer, who hopes that the project will remain viable and keep
evolving in order to remain a viable alternative to Github..