[Trac-dev] Trac's supported dependencies

[Ryan Ollos]

Trac has a number of required and optional dependencies across all its
modules. I've attempted to compile a complete list:
http://trac.edgewall.org/wiki/TracDev/ApiChanges/1.1.4

The issue of which versions we support has come up in the following case -
Subversion 1.6 is no longer supported (1) and I'm considering implementing
a change that would be supported in Subversion 1.7, but not in 1.6 (2). It
would be great if we could drop support for Subversion 1.6 in Trac 1.2, but
I feel there should be a formal process for approaching this.

In some cases we have not been explicit (as far as I know) about what
versions of the dependencies we support. A good place to start would be to
have an informal list of platforms that we are aiming to support. We can
then use that list to decide which versions of the dependencies we'll aim
to support. For example, although Subversion 1.6 is now unsupported by the
Subversion developers, we would want to continue to support it if it was
provided by the official package manager of one the versions of the
platforms we are aiming to support.

The list of platforms I came up with is: Ubuntu, Debian, Red Hat / CentOS,
Fedora, Suse / OpenSuse, FreeBSD, Windows, Windows Server, Mac OSX.

What are people using that I overlooked? It might be a good question to
raise in a dedicated thread on trac-users.

In general I think it's sufficient to say that we will aim to support the
most recent LTS release with each major release of Trac, provided the LTS
release has been out for a while, say 6 months. I'm most familiar with
Ubuntu and Debian, so I would say that we should aim to support Ubuntu
14.04 and Debian 7 with the 1.2 release of Trac.

What I have in mind is to compile a list of platforms we support, and then
list the versions of the dependencies provided by the platforms. From that
we can generate the table of supported dependencies. If this seems like a
good plan, I'm hoping that those familiar with the platforms can help
generate the list.

Another motivation is, it's burdensome to fix issues associated with old
packages. If we don't state that, for example, Pygments < 1.0 is
unsupported (1.0 was released in 2008) and someone finds an issue with 0.6,
then in my mind we are obligated to fix the issue. Even if Trac will work
with a 5 year old dependency, it would be better to just head off potential
issues and enforce a requirement in the codebase, or at least specify it in
the documentation.

Thank you for any input on the issue!

- Ryan


(1)
https://subversion.apache.org/docs/release-notes/1.8.html#svn-1.6-deprecation
(2) http://trac.edgewall.org/ticket/11703#comment:5

[Peter Suter]

Thanks for bringing this up. I think explicitly documenting and
enforcing the supported dependencies is a great idea.

- Subversion 1.6 is no longer supported (1) and I'm considering
implementing a change that would be supported in Subversion 1.7, but not
in 1.6 (2). It would be great if we could drop support for Subversion
1.6 in Trac 1.2, but I feel there should be a formal process for
approaching this.

Sounds reasonable.

The list of platforms I came up with is: Ubuntu, Debian, Red Hat /
CentOS, Fedora, Suse / OpenSuse, FreeBSD, Windows, Windows Server, Mac OSX.
What are people using that I overlooked? It might be a good question to
raise in a dedicated thread on trac-users.

On t.e.o. TitleIndex [3] one can see many TracOn* pages. I don't use any
of these, but apparently at some point at least someone used:

* Arch Linux [4]
* Ark Linux [5] (Discontinued?)
* Gentoo Linux [6]
* Mac OS X Server [7] (Discontinued?)
* Mandrake Linux [8] (Discontinued?)
* Mandriva Linux [9]
* NetBSD [10]
* OpenBSD [11]
* OpenSolaris [12][13]
* Slackware Linux [14]
* ... (I think you mentioned the others, but I may have missed some.)

I don't know if these are (still) in common use though. Your list is
probably already more than sufficient for checking available versions of
dependencies.

[3] http://trac.edgewall.org/wiki/TitleIndex
[4] http://trac.edgewall.org/wiki/TracOnArchLinux
[5] http://trac.edgewall.org/wiki/TracOnArkLinux
[6] http://trac.edgewall.org/wiki/TracOnGentoo
[7] http://trac.edgewall.org/wiki/TracOnLeopardServer
[8] http://trac.edgewall.org/wiki/TracOnMandrakelinux
[9] http://trac.edgewall.org/wiki/TracOnMandriva
[10] http://trac.edgewall.org/wiki/TracOnNetBsd
[11] http://trac.edgewall.org/wiki/TracOnOpenBSD
[12] http://trac.edgewall.org/wiki/TracOnOpenSolaris
[13] http://trac.edgewall.org/wiki/TracOnSolaris
[14] http://trac.edgewall.org/wiki/TracOnSlackware

Reorganization of these pages in a TracOnPlatform/* hierarchy might be
helpful for keeping a [[TitleIndex(./)]] of all platforms.

[Peter Suter]

Post by Peter Suter
[3] http://trac.edgewall.org/wiki/TitleIndex
[4] http://trac.edgewall.org/wiki/TracOnArchLinux
[5] http://trac.edgewall.org/wiki/TracOnArkLinux
[6] http://trac.edgewall.org/wiki/TracOnGentoo
[7] http://trac.edgewall.org/wiki/TracOnLeopardServer
[8] http://trac.edgewall.org/wiki/TracOnMandrakelinux
[9] http://trac.edgewall.org/wiki/TracOnMandriva
[10] http://trac.edgewall.org/wiki/TracOnNetBsd
[11] http://trac.edgewall.org/wiki/TracOnOpenBSD
[12] http://trac.edgewall.org/wiki/TracOnOpenSolaris
[13] http://trac.edgewall.org/wiki/TracOnSolaris
[14] http://trac.edgewall.org/wiki/TracOnSlackware
Reorganization of these pages in a TracOnPlatform/* hierarchy might be
helpful for keeping a [[TitleIndex(./)]] of all platforms.

Or under the existing TracInstallPlatforms page. [15]

[15] http://trac.edgewall.org/wiki/TracInstallPlatforms

[Ryan Ollos]

Post by Peter Suter

Post by Peter Suter
[3] http://trac.edgewall.org/wiki/TitleIndex
[4] http://trac.edgewall.org/wiki/TracOnArchLinux
[5] http://trac.edgewall.org/wiki/TracOnArkLinux
[6] http://trac.edgewall.org/wiki/TracOnGentoo
[7] http://trac.edgewall.org/wiki/TracOnLeopardServer
[8] http://trac.edgewall.org/wiki/TracOnMandrakelinux
[9] http://trac.edgewall.org/wiki/TracOnMandriva
[10] http://trac.edgewall.org/wiki/TracOnNetBsd
[11] http://trac.edgewall.org/wiki/TracOnOpenBSD
[12] http://trac.edgewall.org/wiki/TracOnOpenSolaris
[13] http://trac.edgewall.org/wiki/TracOnSolaris
[14] http://trac.edgewall.org/wiki/TracOnSlackware
Reorganization of these pages in a TracOnPlatform/* hierarchy might be
helpful for keeping a [[TitleIndex(./)]] of all platforms.

Or under the existing TracInstallPlatforms page. [15]
[15] http://trac.edgewall.org/wiki/TracInstallPlatforms

Reorganizing the pages in a hierarchy seems like a good idea. We could
leave a redirect on the old page for some time, and then delete the page
after 6 months or 12 months ... whatever is deemed a sufficient amount of
time.

Would having a real redirect macro in the core help, particularly one that
returns the proper HTTP status code for a moved page? Something like:
http://trac-hacks.org/wiki/ServerSideRedirectPlugin

The more difficult issue is determining when to remove the pages because
they are so out-of-date as to do more harm than good. It would be really
nice if we had dedicated maintainers of the pages for each platform. In
absence of that, I guess the only thing to do is to run through each one
and decide whether to update or remove it.

[RjOllos]

Post by Peter Suter

Post by Peter Suter
[3] http://trac.edgewall.org/wiki/TitleIndex
[4] http://trac.edgewall.org/wiki/TracOnArchLinux
[5] http://trac.edgewall.org/wiki/TracOnArkLinux
[6] http://trac.edgewall.org/wiki/TracOnGentoo
[7] http://trac.edgewall.org/wiki/TracOnLeopardServer
[8] http://trac.edgewall.org/wiki/TracOnMandrakelinux
[9] http://trac.edgewall.org/wiki/TracOnMandriva
[10] http://trac.edgewall.org/wiki/TracOnNetBsd
[11] http://trac.edgewall.org/wiki/TracOnOpenBSD
[12] http://trac.edgewall.org/wiki/TracOnOpenSolaris
[13] http://trac.edgewall.org/wiki/TracOnSolaris
[14] http://trac.edgewall.org/wiki/TracOnSlackware
Reorganization of these pages in a TracOnPlatform/* hierarchy might be
helpful for keeping a [[TitleIndex(./)]] of all platforms.

Or under the existing TracInstallPlatforms page. [15]
[15] http://trac.edgewall.org/wiki/TracInstallPlatforms

Another seemingly fitting location for the hierarchy is
CookBook/Installation:

http://trac.edgewall.org/wiki/CookBook/Installation

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Peter Suter
[3] http://trac.edgewall.org/wiki/TitleIndex

<http://trac.edgewall.org/wiki/TitleIndex>

Post by Peter Suter
[4] http://trac.edgewall.org/wiki/TracOnArchLinux

<http://trac.edgewall.org/wiki/TracOnArchLinux>

Post by Peter Suter
[5] http://trac.edgewall.org/wiki/TracOnArkLinux

<http://trac.edgewall.org/wiki/TracOnArkLinux>

...

Post by Peter Suter
Reorganization of these pages in a TracOnPlatform/* hierarchy

might be

Post by Peter Suter
helpful for keeping a [[TitleIndex(./)]] of all platforms.

Or under the existing TracInstallPlatforms page. [15]
[15] http://trac.edgewall.org/wiki/TracInstallPlatforms
<http://trac.edgewall.org/wiki/TracInstallPlatforms>
Another seemingly fitting location for the hierarchy is
http://trac.edgewall.org/wiki/CookBook/Installation

You meant something like wiki/CookBook/InstallOn/<platform>?
If so, nice idea.

Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlTiU2QACgkQ31DJeiZFuHcRsQCdHlRiYQR2Yt1uLQy1siKVPJ+h
HKcAoM5echuZIBFjqoXqOgaPSuCzPMDl
=IpzM
-----END PGP SIGNATURE-----

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Ryan Ollos
In general I think it's sufficient to say that we will aim to support
the most recent LTS release with each major release of Trac, provided
the LTS release has been out for a while, say 6 months. I'm most
familiar with Ubuntu and Debian, so I would say that we should aim to
support Ubuntu 14.04 and Debian 7 with the 1.2 release of Trac.

Nit-pick: At least from Debian side it should rather be Debian 8, as
long as Trac 1.2 is not right around the corner. I don't know so much
about Ubuntu.

Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlTXgBkACgkQ31DJeiZFuHeL2ACeP26R/+SGEMccGLpNAW34bmzI
9n8An2ZvZd8fNEwtesIS3R+V60x4cwoZ
=w1Mc
-----END PGP SIGNATURE-----

[Ryan Ollos]

Post by Steffen Hoffmann
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Ryan Ollos
In general I think it's sufficient to say that we will aim to support
the most recent LTS release with each major release of Trac, provided
the LTS release has been out for a while, say 6 months. I'm most
familiar with Ubuntu and Debian, so I would say that we should aim to
support Ubuntu 14.04 and Debian 7 with the 1.2 release of Trac.

Nit-pick: At least from Debian side it should rather be Debian 8, as
long as Trac 1.2 is not right around the corner. I don't know so much
about Ubuntu.
Steffen Hoffmann

In a recent thread I proposed around May 1st for the Trac 1.2 release, but
it's still too soon to say for sure,
https://groups.google.com/d/msg/trac-dev/09KHkId-deE/Mg8M6jt-uywJ

A quick search didn't yield a release date for Debian 8, do you know of one?

Ubuntu provides an LTS release every 2 years. The most recent was 14.04,
the next will be 16.04 (April 2016).
https://wiki.ubuntu.com/LTS

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Ryan Ollos
A quick search didn't yield a release date for Debian 8, do you know of one?

No, they don't tell and stick to the declaration "Release only when
everything is ready." [1], but I felt like it's closing down, because
there was a release candidate, that was discussed by early adopters.

Steffen Hoffmann



[1] https://wiki.debian.org/ReleaseWhenReady

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlTX6/0ACgkQ31DJeiZFuHcJmACgmlBD2RI2mQXQEKfwYxvtLsjf
sp0An28d86UYo1PUSxco0YKlkAEa/0c/
=y/Cx
-----END PGP SIGNATURE-----

[Benjamin Lau]

As Steffen said they follow a "Release only when everything is ready"
philosophy. But you can get an idea of where they are in the process
by following the Release Critical Bug report notices[1]. Based on the
latest one compared to previous ones Debian 8 is probably about 3
months away.

Cheers,
Ben

[1] http://richardhartmann.de/tags/tech/floss/debian/rc-stats/8.0-jessie/

Post by Steffen Hoffmann
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Ryan Ollos
A quick search didn't yield a release date for Debian 8, do you know of one?

No, they don't tell and stick to the declaration "Release only when
everything is ready." [1], but I felt like it's closing down, because
there was a release candidate, that was discussed by early adopters.
Steffen Hoffmann
[1] https://wiki.debian.org/ReleaseWhenReady
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlTX6/0ACgkQ31DJeiZFuHcJmACgmlBD2RI2mQXQEKfwYxvtLsjf
sp0An28d86UYo1PUSxco0YKlkAEa/0c/
=y/Cx
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
Visit this group at http://groups.google.com/group/trac-dev.
For more options, visit https://groups.google.com/d/optout.

[Greg Troxel]

Ryan Ollos <***@gmail.com> writes:

I'm commenting as the maintainer of trac packages in pkgsrc (since about
2007/2008), which is a multi-OS packaging system that is native on
NetBSD and SmartOS (an Illumos variant) and which works on FreeBSD,
OpenBSD, probably DragonFly, Linux, OS X, solaris/illumos, and also more
obscure platforms like AIX, IRIX, and Cygwin.

The trac package does not depend on svn or git. By default it depends
on sqlite3, but one can switch to pgsql (via psycopg2).

Post by Ryan Ollos
The issue of which versions we support has come up in the following case -
Subversion 1.6 is no longer supported (1) and I'm considering implementing
a change that would be supported in Subversion 1.7, but not in 1.6 (2). It
would be great if we could drop support for Subversion 1.6 in Trac 1.2, but
I feel there should be a formal process for approaching this.

This is tricky. It's not about pkgsrc - I have 1.8.11 installed now,
but it seems people like to keep servers at older versions. It does
seem reasonable for 1.2 to drop 1.6, and let 1.0.x keep working with
1.6.

Post by Ryan Ollos
The list of platforms I came up with is: Ubuntu, Debian, Red Hat / CentOS,
Fedora, Suse / OpenSuse, FreeBSD, Windows, Windows Server, Mac OSX.

NetBSD, and I'd say Illumos. (I have trac in production on NetBSD on
multiple servers, with both svn and git).

Post by Ryan Ollos
In general I think it's sufficient to say that we will aim to support the
most recent LTS release with each major release of Trac, provided the LTS
release has been out for a while, say 6 months. I'm most familiar with
Ubuntu and Debian, so I would say that we should aim to support Ubuntu
14.04 and Debian 7 with the 1.2 release of Trac.

The concept of a single release only really applies to Linux
distributions.

With pkgsrc, there is a new stable branch every quarter. trac will be
ok if it works with the versions of dependencies that are in the same
stable branch. As long as you are ok working with a stable release of a
dependency that was current (*actually released* with a tarball and a
non-beta designation) 1 year ago, I am 99% sure there will be zero
issues. Probably even for 3 months.

Then, there are multiple stable branches of the OS. With NetBSD,
there's 5, which is old but supported, 6 which is current, and 7 about
to be released. But I am sure trac 1.0.x is ok on 5 (I run it) and
surely it is fine on 6. So this is not actually that tricky in practice
for trac. The usual packager-friendly guidlines of not demanding
bleeding-edge versions and not demanding exact matches apply.

It's definitely ok to only support python 2.6 and 2.7. pkgsrc has both
and 2.7 is normal and 2.6 for those who have to run old code.

A big question you didn't ask is databases. I use postgresql, because
it's been solid for a long time and has had real transactions. I have
found sometimes that when I upgrade postgresql to a newer version I have
trouble with some plugins and have e.g. to make the SQL more careful
about types. Surely others use mysql, but I am less familiar with
versions, and my impression is that the project does not recommend it.
Probably sqlite3 does not have issues with different versions.

For postgresql, I know mastertickets and sensitivetickets work with
postgresql 8.4. I have not tried newer. I would probably recommend 9.2
for new installs.

Post by Ryan Ollos
What I have in mind is to compile a list of platforms we support, and then
list the versions of the dependencies provided by the platforms. From that
we can generate the table of supported dependencies. If this seems like a
good plan, I'm hoping that those familiar with the platforms can help
generate the list.

On pkgsrc from the 2014Q4 branch (released in the last days of 2014):

subversion 1.8.11
git 2.2.1
py27-genshi-0.7
py27-pygments-2.0.1nb1
py27-babel-1.3nb1

and not apparently required, but FYI:

py27-sphinx-1.2.3

But, I'm pretty sure that pkgsrc, with the quarterly update model and
no LTS concept, will not be trailing edge on any dependencies.

I deal with a lot of upstreams. Trac core has not been an issue, so I
think things aren't broken and it's good to tread lightly on deprecating
svn 1.6. It's fine to deprecate python 2.5 (and 2.4).

I often see people with ancient RH/centos systems who for some reason
want to run really old base code like python but also run new things
like trac. I think this doesn't make sense; one should either keep up
or not keep up, but not have it both ways. One can install pkgsrc on
such a system and have a trac/python (and web server, database) install
that is up to date, even if the base system is old.

With the plugins, I'd like to see them each have real releases with
version numbers and tarballs. pkgsrc is basically opposed to packaging
git snapshots, and it's a bug in the current git culture that saying
some hash is stable is viewed to be as good as a real release. This has
gotten better, but seems not 100% ok across the variety of plugins.
Plus, I'd like to see plugins tested with recent pgsql (and mysql).

That's my packager rant -- thanks for asking to hear it!!!

[Jun Omae]

Post by Ryan Ollos
The issue of which versions we support has come up in the following case -
Subversion 1.6 is no longer supported (1) and I'm considering implementing a
change that would be supported in Subversion 1.7, but not in 1.6 (2). It
would be great if we could drop support for Subversion 1.6 in Trac 1.2, but
I feel there should be a formal process for approaching this.

-1 to dropping support for 1.6.

RHEL6/CentOS6 provide full updates until 2017Q2. Subversion 1.6.11 is
used in the distributions.

http://wiki.centos.org/About/Product
https://access.redhat.com/support/policy/updates/errata

Also, it would be good to add authz_file option per a repository, even
if supported subversion is 1.6+ or 1.7+. If a user is using Subversion
1.7 and AuthzSVNReposRelativeAccessFile, the option is valuable to the
users. However, if AuthzSVNAccessFile is used, [trac] authz_file
option must be needed for the users.

[Ryan Ollos]

Post by Ryan Ollos
The issue of which versions we support has come up in the following case

-

Post by Ryan Ollos
Subversion 1.6 is no longer supported (1) and I'm considering

implementing a

Post by Ryan Ollos
change that would be supported in Subversion 1.7, but not in 1.6 (2). It
would be great if we could drop support for Subversion 1.6 in Trac 1.2,

but

Post by Ryan Ollos
I feel there should be a formal process for approaching this.

-1 to dropping support for 1.6.
RHEL6/CentOS6 provide full updates until 2017Q2. Subversion 1.6.11 is
used in the distributions.

It would be helpful if you could clarify.

Are you:
- Against dropping support for SVN 1.6 until 2017Q2?
- Against dropping support for SVN 1.6 in Trac 1.0.x?
- Against dropping support for SVN 1.6 in Trac 1.2.x?

What about when we start development on the 1.3.x line? (which could be as
early as May 2015)

If RHEL6/CentOS6 "provides full updates", why haven't they updated to a
version of Subversion that is supported by the Subversion team? Which
version of Trac is currently provided by RHEL6/CentOS6?

[Jun Omae]

Post by Ryan Ollos

Post by Jun Omae
-1 to dropping support for 1.6.
RHEL6/CentOS6 provide full updates until 2017Q2. Subversion 1.6.11 is
used in the distributions.

It would be helpful if you could clarify.
- Against dropping support for SVN 1.6 in Trac 1.2.x?

I mean it that disagree against dropping support for SVN 1.6 in Trac 1.2.x.

Hummm, I would agree dropping SVN 1.6 if it means that Trac 1.2.x is
likely to work with SVN 1.6, but the version is not officially
supported.

Post by Ryan Ollos
What about when we start development on the 1.3.x line? (which could be as
early as May 2015)
If RHEL6/CentOS6 "provides full updates", why haven't they updated to a
version of Subversion that is supported by the Subversion team? Which
version of Trac is currently provided by RHEL6/CentOS6?

RHEL/CentOS provide security patches if upstream stopped maintenance.

RHEL/CentOS 5, 6 and 7 don't provide Trac package.
See http://rpmfind.net/linux/rpm2html/search.php?query=Trac

[Greg Troxel]

Post by Jun Omae
I mean it that disagree against dropping support for SVN 1.6 in Trac 1.2.x.
Hummm, I would agree dropping SVN 1.6 if it means that Trac 1.2.x is
likely to work with SVN 1.6, but the version is not officially
supported.

I still am having trouble understanding the thought process here. Why
do people think it's ok to stay with old subversion but not to stay with
old trac (1.0.x)?

[Ryan Ollos]

Post by Jun Omae

Post by Jun Omae
I mean it that disagree against dropping support for SVN 1.6 in Trac

1.2.x.

Post by Jun Omae
Hummm, I would agree dropping SVN 1.6 if it means that Trac 1.2.x is
likely to work with SVN 1.6, but the version is not officially
supported.

I still am having trouble understanding the thought process here. Why
do people think it's ok to stay with old subversion but not to stay with
old trac (1.0.x)?

I am with you on that.

It still potentially hurts us if we can't make incompatible changes with
SVN 1.6.

I don't agree with having Trac held back so that users running old versions
of Red Hat can run the latest version of Trac. Those users can run an old
version of Trac, after all they are running an old version of SVN, so they
are apparently okay with not having the latest and greatest of everything.
If they don't want to run an old version of Trac they can upgrade their OS.
Everything has a cost, and going out of our way to support old platforms
will slow the project. That's why I was hoping we could adopt a rule, such
as supporting the latest version from a set of informally supported OS's
available at the time of a major release. That would imply we should target
RHEL7/CentOS7 with the next major release, 1.2.

Assuming we do try to maintain compatibility with RHEL6/CentOS6, I was even
more concerned that we'd have to continue supporting Python 2.6 for the
next several years due to RHEL6/CentOS6. It appears at least they provide
Python 2.7:
http://rpmfind.net/linux/rpm2html/search.php?query=python&submit=Search+...&system=&arch=

[Ryan Ollos]

Post by Ryan Ollos

Post by Jun Omae

Post by Jun Omae
I mean it that disagree against dropping support for SVN 1.6 in Trac

1.2.x.

Post by Jun Omae
Hummm, I would agree dropping SVN 1.6 if it means that Trac 1.2.x is
likely to work with SVN 1.6, but the version is not officially
supported.

I still am having trouble understanding the thought process here. Why
do people think it's ok to stay with old subversion but not to stay with
old trac (1.0.x)?

I am with you on that.
It still potentially hurts us if we can't make incompatible changes with
SVN 1.6.
I don't agree with having Trac held back so that users running old
versions of Red Hat can run the latest version of Trac. Those users can run
an old version of Trac, after all they are running an old version of SVN,
so they are apparently okay with not having the latest and greatest of
everything. If they don't want to run an old version of Trac they can
upgrade their OS. Everything has a cost, and going out of our way to
support old platforms will slow the project. That's why I was hoping we
could adopt a rule, such as supporting the latest version from a set of
informally supported OS's available at the time of a major release. That
would imply we should target RHEL7/CentOS7 with the next major release, 1.2.
Assuming we do try to maintain compatibility with RHEL6/CentOS6, I was
even more concerned that we'd have to continue supporting Python 2.6 for
the next several years due to RHEL6/CentOS6. It appears at least they
http://rpmfind.net/linux/rpm2html/search.php?query=python&submit=Search+...&system=&arch=

I didn't setup that filter correctly and it appears the info isn't
available through that database. From a quick search it appears that
RHEL6/CentOS6 may not provide Python 2.7:
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/
http://distrowatch.com/table.php?distribution=redhat

Dropping support for Python 2.6 is an issue really worth discussing.
Keeping supporting for Python 2.6 indefinitely is something that will
really slow us down and make it even harder to get to Python 3.x someday.
We have already committed to supporting Python 2.6 in Trac 1.2.x, but I'd
like to drop support for Python 2.6 starting with 1.3.1. I'm really tired
of testing on multiple versions of Python and worrying about using
incompatible features. The situation has gotten better now that we don't
develop Trac 0.12.x, which supports Python 2.4, but we still have to worry
about Python 2.5 in Trac 1.0.x, and I'm eager to move on. By this time next
year it would be ideal if development was focused on 1.3.x and we only had
to test against Python 2.7.

[Christian Boos]

On 2/9/2015 7:11 PM, Ryan Ollos wrote:/

Post by Ryan Ollos
Dropping support for Python 2.6 is an issue really worth discussing.
Keeping supporting for Python 2.6 indefinitely is something that will
really slow us down and make it even harder to get to Python 3.x
someday. We have already committed to supporting Python 2.6 in Trac
1.2.x, but I'd like to drop support for Python 2.6 starting with 1.3.1.
I'm really tired of testing on multiple versions of Python and worrying
about using incompatible features. The situation has gotten better now
that we don't develop Trac 0.12.x, which supports Python 2.4, but we
still have to worry about Python 2.5 in Trac 1.0.x, and I'm eager to
move on. By this time next year it would be ideal if development was
focused on 1.3.x and we only had to test against Python 2.7.

I agree. Besides:

Trac 0.11 - last version to work with Python 2.3
Trac 0.12 - last version to work with Python 2.4
Trac 1.0 - last version to work with Python 2.5
Trac 1.2 - last version to work with Python 2.6

That sequence looks good to me ;-)

-- Christian

[Tetsuya Morimoto]

Post by Ryan Ollos
Dropping support for Python 2.6 is an issue really worth discussing.

RHEL/CentOS provide additional external repository, named Software
Collections Repository (SCL). These repositories are supported by Red Hat
officially. For example, above RHEL6/CentOS6, we can switch
Python2.7/Python3.3 using SCL.

https://www.softwarecollections.org/en/
https://access.redhat.com/products/Red_Hat_Enterprise_Linux/Developer/#rhscl=&dev-page=5
http://wiki.centos.org/AdditionalResources/Repositories/SCL

Of course, LTS support is also good. What I would want to say is that we
don't need to stick around supporting legacy Python version.

thanks,
Tetsuya

Post by Ryan Ollos

Post by Ryan Ollos

Post by Jun Omae

Post by Jun Omae
I mean it that disagree against dropping support for SVN 1.6 in Trac

1.2.x.

Post by Jun Omae
Hummm, I would agree dropping SVN 1.6 if it means that Trac 1.2.x is
likely to work with SVN 1.6, but the version is not officially
supported.

I still am having trouble understanding the thought process here. Why
do people think it's ok to stay with old subversion but not to stay with
old trac (1.0.x)?

I am with you on that.
It still potentially hurts us if we can't make incompatible changes with
SVN 1.6.
I don't agree with having Trac held back so that users running old
versions of Red Hat can run the latest version of Trac. Those users can run
an old version of Trac, after all they are running an old version of SVN,
so they are apparently okay with not having the latest and greatest of
everything. If they don't want to run an old version of Trac they can
upgrade their OS. Everything has a cost, and going out of our way to
support old platforms will slow the project. That's why I was hoping we
could adopt a rule, such as supporting the latest version from a set of
informally supported OS's available at the time of a major release. That
would imply we should target RHEL7/CentOS7 with the next major release, 1.2.
Assuming we do try to maintain compatibility with RHEL6/CentOS6, I was
even more concerned that we'd have to continue supporting Python 2.6 for
the next several years due to RHEL6/CentOS6. It appears at least they
http://rpmfind.net/linux/rpm2html/search.php?query=python&submit=Search+...&system=&arch=

I didn't setup that filter correctly and it appears the info isn't
available through that database. From a quick search it appears that
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/
http://distrowatch.com/table.php?distribution=redhat
Dropping support for Python 2.6 is an issue really worth discussing.
Keeping supporting for Python 2.6 indefinitely is something that will
really slow us down and make it even harder to get to Python 3.x someday.
We have already committed to supporting Python 2.6 in Trac 1.2.x, but I'd
like to drop support for Python 2.6 starting with 1.3.1. I'm really tired
of testing on multiple versions of Python and worrying about using
incompatible features. The situation has gotten better now that we don't
develop Trac 0.12.x, which supports Python 2.4, but we still have to worry
about Python 2.5 in Trac 1.0.x, and I'm eager to move on. By this time next
year it would be ideal if development was focused on 1.3.x and we only had
to test against Python 2.7.
--
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
Visit this group at http://groups.google.com/group/trac-dev.
For more options, visit https://groups.google.com/d/optout.

[RjOllos]

Post by Ryan Ollos

Post by Jun Omae

Post by Jun Omae
I mean it that disagree against dropping support for SVN 1.6 in Trac

1.2.x.

Post by Jun Omae
Hummm, I would agree dropping SVN 1.6 if it means that Trac 1.2.x is
likely to work with SVN 1.6, but the version is not officially
supported.

I still am having trouble understanding the thought process here. Why
do people think it's ok to stay with old subversion but not to stay with
old trac (1.0.x)?

I am with you on that.
It still potentially hurts us if we can't make incompatible changes with
SVN 1.6.
I don't agree with having Trac held back so that users running old
versions of Red Hat can run the latest version of Trac. Those users can run
an old version of Trac, after all they are running an old version of SVN,
so they are apparently okay with not having the latest and greatest of
everything. If they don't want to run an old version of Trac they can
upgrade their OS. Everything has a cost, and going out of our way to
support old platforms will slow the project. That's why I was hoping we
could adopt a rule, such as supporting the latest version from a set of
informally supported OS's available at the time of a major release. That
would imply we should target RHEL7/CentOS7 with the next major release, 1.2.
Assuming we do try to maintain compatibility with RHEL6/CentOS6, I was
even more concerned that we'd have to continue supporting Python 2.6 for
the next several years due to RHEL6/CentOS6. It appears at least they
http://rpmfind.net/linux/rpm2html/search.php?query=python&submit=Search+...&system=&arch=

Looking forward to the Trac 1.3.x development line, I think it would be
beneficial to document the versions of packages provided by the platforms
we intend to remain compatible with. I've started that for Ubuntu here:
http://trac.edgewall.org/wiki/TracDev/ApiChanges/1.3.1#CompatibleDistros

Please add to it if you would like.

[Greg Troxel]

Post by Jun Omae
-1 to dropping support for 1.6.

For the record, svn 1.7.0 was released on 2011-10-10 (or that's the
tarball date), and 1.7.2 on 2011-12-05. That's a little more recent
than I expected. The subversion project no longer supports 1.6.

Post by Jun Omae
RHEL6/CentOS6 provide full updates until 2017Q2. Subversion 1.6.11 is
used in the distributions.

What version of trac do they provide? Why isn't that ok for people that
want to use a distribution that doesn't have updates? I'm actually
serious with this question - I just don't understand the thought process
that goes into this.

Also, people on RHEL6 can install pkgsrc and build all of trac's
dependencies, and get modern versions. Or by hand - if one is going to
build new trac, why can't one build new subversion?

['Felix Schwarz' via Trac Development]

Hi,

Post by Greg Troxel

Post by Jun Omae
RHEL6/CentOS6 provide full updates until 2017Q2. Subversion 1.6.11 is
used in the distributions.

What version of trac do they provide?

RHEL does not provide trac itself. Fedora EPEL 5+6 shipped old versions of
trac but we'll likely retire these versions.

Post by Greg Troxel
Why isn't that ok for people that want to use a distribution that doesn't
have updates? I'm actually serious with this question - I just don't
understand the thought process that goes into this.

Red Hat promises to support this Subversion version so they will do everything
necessary to resolve critical bugs (or backport fixes), provide support
(depending on your Red Hat contract) and of course fix security issues. Red
Hat employs many hundred (thousand?) Open source developers specifically so
they have the knowledge to fix all of their supported components if necessary.

Red Hat also still supports Python 2.4 and old PHP versions for example.

So basically with RHEL you get a base OS which "just works" and you should be
able to install all provided updates without any issues.

For EPEL this is different because it's just community-supported.

Post by Greg Troxel
Also, people on RHEL6 can install pkgsrc and build all of trac's
dependencies, and get modern versions. Or by hand - if one is going to
build new trac, why can't one build new subversion?

Well, it's much easiert to install Trac than to compile subversion (e.g. "no
compilation required for trac"). Also replacing subversion is not so easy
because there might be a lot of other tools (e.g. Apache integration) which
need to be recompiled as well.

Generally RHEL users don't want to replace system components but rely on Red
Hat engineers for that and they they are doing a great job.

Felix

[RjOllos]

Post by Ryan Ollos
Trac has a number of required and optional dependencies across all its
http://trac.edgewall.org/wiki/TracDev/ApiChanges/1.1.4
The issue of which versions we support has come up in the following case -
Subversion 1.6 is no longer supported (1) and I'm considering implementing
a change that would be supported in Subversion 1.7, but not in 1.6 (2). It
would be great if we could drop support for Subversion 1.6 in Trac 1.2, but
I feel there should be a formal process for approaching this.
In some cases we have not been explicit (as far as I know) about what
versions of the dependencies we support. A good place to start would be to
have an informal list of platforms that we are aiming to support. We can
then use that list to decide which versions of the dependencies we'll aim
to support. For example, although Subversion 1.6 is now unsupported by the
Subversion developers, we would want to continue to support it if it was
provided by the official package manager of one the versions of the
platforms we are aiming to support.
The list of platforms I came up with is: Ubuntu, Debian, Red Hat / CentOS,
Fedora, Suse / OpenSuse, FreeBSD, Windows, Windows Server, Mac OSX.
What are people using that I overlooked? It might be a good question to
raise in a dedicated thread on trac-users.

I've forked this discussion since the original thread could get rather
lengthy. I prepared the following to post to trac-users, and hoping to get
some input on improving the questions before posting it there. Does anyone
anticipate that we'll get useful info this way? Is there a better way?

---

Recent discussion on the trac-dev (1) mailing list has focused on trying to
determine which dependencies we need to support, by considering the most
common platforms that Trac runs on. I'm hoping to get some data that is an
extension of what we see on TracUsers (2).

If you would be so kind as to answer the following questions:

1. Which Trac version are you running?
2. Which OS and what version of the OS are you running?
3. Do you run your own server, use shared hosting (e.g. a VM through a
hosting provider) or use an instance of Trac managed by a hosting provider
from their servers? Please indicate if you are a hosting provider rather
than an end-user.
4. Did you install Trac via your OS's package manager, by directly
installing from a package or source (e.g. pip, easy_install, exe or msi
installer or direct checkout) or are you running from a prepared image
(e.g. Bitnami installer or VM)?
5. If you are running an older version of Trac, are you limited by the
version provided by your OS package manager, by a dependency that is not
supported in a newer version of Trac (e.g. Python 2.4) or by what is
provided by your hosting company?
6. If you are running an older version of an OS, what are the obstacles to
upgrading?


(1) https://groups.google.com/d/msg/trac-dev/nkMUY_8ILF0/rg1rsArDIewJ
(2) http://trac.edgewall.org/wiki/TracUsers

Post by Ryan Ollos
In general I think it's sufficient to say that we will aim to support the
most recent LTS release with each major release of Trac, provided the LTS
release has been out for a while, say 6 months. I'm most familiar with
Ubuntu and Debian, so I would say that we should aim to support Ubuntu
14.04 and Debian 7 with the 1.2 release of Trac.
What I have in mind is to compile a list of platforms we support, and then
list the versions of the dependencies provided by the platforms. From that
we can generate the table of supported dependencies. If this seems like a
good plan, I'm hoping that those familiar with the platforms can help
generate the list.
Another motivation is, it's burdensome to fix issues associated with old
packages. If we don't state that, for example, Pygments < 1.0 is
unsupported (1.0 was released in 2008) and someone finds an issue with 0.6,
then in my mind we are obligated to fix the issue. Even if Trac will work
with a 5 year old dependency, it would be better to just head off potential
issues and enforce a requirement in the codebase, or at least specify it in
the documentation.
Thank you for any input on the issue!
- Ryan
(1)
https://subversion.apache.org/docs/release-notes/1.8.html#svn-1.6-deprecation
(2) http://trac.edgewall.org/ticket/11703#comment:5

['Felix Schwarz' via Trac Development]

I guess the situation for Fedora is pretty simple:
- Fedora releases every 6-9 months and supports a release N approximately
for 1-2 months after the N+2 release is out.
Generally Fedora ships the latest versions and we don't have any issues
with old dependencies.

- RHEL/CentOS is a bit more tricky:
- RHEL 5 is supported (as in "end of production 3") until 2017
- Python 2.4
- subversion 1.6.11
- RHEL 6 support ends 2020
- Python 2.6
- subversion 1.6.11
- RHEL 7 should be good until 2024
- Python 2.7
- subversion 1.7.14

From what I can see there is very little active maintenance anymore for
packages in Fedora EPEL 5 (add-ons for RHEL/CentOS 5) which means that most
people running these versions are just satisfied with the status quo, not much
need for newer versions (in which case they'll likely just upgrade).
Most web hosts also upgraded at least to RHEL 6 also to provide newer versions
of PHP.

Maybe as a general rule most people stop caring about new features for a
RHEL/CentOS release about 7 years after the initial introduction which means
"end of production 2" (Red Hat provides maintenance updates only from that
point on).

For RHEL 6 that means people likely care about that release until 2017.

That being said personally I'd not veto a change like you proposed ("support
the most recent LTS release with each major release of Trac, provided the LTS
release has been out for a while, say 6 months") if it makes life easier.

For Fedora EPEL we're in a mess anyhow because:
- Trac 1.1 is guaranteed to be compatible
- EPEL does not have a deprecation policy so we could introduce major
version upgrades in a well-understood way which does not catch EPEL users
by surprise.

Felix