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.

On 08.02.2015 07:19, Ryan Ollos wrote:
> - 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]

On 08.02.2015 09:50, Peter Suter wrote:
> [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

[Steffen Hoffmann]

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

On 08.02.2015 07:19, Ryan Ollos wrote:

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

On Sun, Feb 8, 2015 at 7:26 AM, Steffen Hoffmann <hof...@web.de> wrote:

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

On 08.02.2015 07:19, Ryan Ollos wrote:
> 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

On 08.02.2015 17:35, Ryan Ollos wrote:
> 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/

> --
> 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 post to this group, send email to trac...@googlegroups.com.
> 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 <rjo...@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).

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

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

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

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

On Sun, Feb 8, 2015 at 3:19 PM, Ryan Ollos <rjo...@gmail.com> wrote:
> 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.

--
Jun Omae <jun...@gmail.com> (大前 潤)

[Ryan Ollos]

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]

On Saturday, February 7, 2015 at 10:19:24 PM UTC-8, RjOllos wrote:

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.

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


 

[Ryan Ollos]

On Sun, Feb 8, 2015 at 7:37 PM, Jun Omae <jun...@gmail.com> wrote:

On Sun, Feb 8, 2015 at 3:19 PM, Ryan Ollos <rjo...@gmail.com> wrote:
> 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.

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?

[Felix Schwarz]

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

[Greg Troxel]

Jun Omae <jun...@gmail.com> writes:

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

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

Hi,

Am 09.02.2015 um 13:43 schrieb Greg Troxel:
>> 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.

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

> 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

[Jun Omae]

On Mon, Feb 9, 2015 at 3:10 PM, Ryan Ollos <rjo...@gmail.com> wrote:
>> On Sun, Feb 8, 2015 at 3:19 PM, Ryan Ollos <rjo...@gmail.com> wrote:
>> -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 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.

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

Jun Omae <jun...@gmail.com> writes:

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

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]

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:/

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

> 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

[RjOllos]

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

On 16.02.2015 04:03, RjOllos wrote:
> On Sunday, February 8, 2015 at 2:00:00 AM UTC-8, Peter Suter wrote:
>
> On 08.02.2015 09:50, Peter Suter wrote:
> > [3] http://trac.edgewall.org/wiki/TitleIndex
> <http://trac.edgewall.org/wiki/TitleIndex>
> > [4] http://trac.edgewall.org/wiki/TracOnArchLinux
> <http://trac.edgewall.org/wiki/TracOnArchLinux>
> > [5] http://trac.edgewall.org/wiki/TracOnArkLinux

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

> >
> > 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
> <http://trac.edgewall.org/wiki/TracInstallPlatforms>
>
>
> Another seemingly fitting location for the hierarchy is
> CookBook/Installation:
>
> 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-----

[RjOllos]

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.