Trac 1.4 will be the next LTS release

[RjOllos]

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.

Please share any thoughts.

- Ryan

(1) https://trac.edgewall.org/wiki/RoadMap

[Tawanda Gwena]

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.

----
Tawanda Gwena

> --
> 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+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/trac-dev/7e98da23-3caa-4ffe-a1f4-9088abdc2fa2%40googlegroups.com.

[Niels Sascha Reedijk]

Hi,

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
2.7. 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)[1].

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..

Regards,

Niels

[1] https://www.python.org/dev/peps/pep-0478/

[RjOllos]

On Monday, August 26, 2019 at 6:43:52 PM UTC-7, Tawanda Gwena wrote:

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.

----
Tawanda Gwena

Jinja2 is coming in Trac 1.4, but worth considering to label the Python 3 compatible branch as 2.0.

- Ryan

[RjOllos]

On Monday, August 26, 2019 at 11:35:07 PM UTC-7, Nielx wrote:

Hi,

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?

Unfortunately we may not have a Python 3 compatible version ready by January 1st 2020, and it will take some time for users to switch and get plugins ported to Python 3.

Additionally, you said you also proposed that Trac 1.6 should
_support_ python 3.5+, implying that it should also support python
2.7.

I'm proposing that Trac 1.6 will not support Python 2.7.

 

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)[1].

I'd like to have some official documentation and containers for Trac. From the mailing list activity, it seems many users are not using virtualenvs, let alone containers.

It was years ago that we discussed Python 3.5+.

Python 3.5 is EOL Sept 2020 [2]. I think it makes sense to go with Python 3.6+ at least.

 

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.

Plugins will be ported over time. The Python 3 compatibility changes are fairly minimal for many plugins. Porting to Jinja2 will require a lot of work for some plugins. I hope we can keep most of them alive (or integrate them), otherwise users may stick with Trac 1.4.

 

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..

Regards,

Niels

[1] https://www.python.org/dev/peps/pep-0478/

[2] https://groups.google.com/forum/?nomobile=true#!topic/trac-dev/eAUDDQ_NpBM