On Thu, Mar 11, 2010 at 10:48 AM, Jeremy Whitlock <jcscoobyrs_at_gmail.com> wrote:
>> I don't get this. We are willing to do things like require Python 2.4
>> (which we did in 1.6) and consider requiring APR 1.3. These sorts of
>> things impact a significant number of our users and really bring us as
>> developers only modest benefits in terms of making our lives easier.
> I don't know man. Even Python 2.4 is almost 5 years old already and just "upgrading" it came
> with many things that just made life easier, like subprocess for example. Apache 2.0 is almost
> 11 years old.
How old something is should not be relevant. It should be based on
what it is costing us to still support it. Usually this would only be
an issue if we cannot take advantage of something because of
supporting an older version. The patch to put back Python 2.3 support
is pretty small. I do not see why it was important to us.
> Finally, not only is RHEL4 5 years old but it's reached its EOL.
This is not true. RHEL 3 is even still in support until later this
year. RHEL 4 has simply transitioned to a phase of support where the
criteria for making a fix is higher.
There are a lot of reasons enterprises run these older versions, and
they are not all that they want to just run older versions. They
could have hardware driver issues they are dealing with or they could
have applications that require the older versions and have not been
updated etc. We should not stop supporting these users unless we have
Like I said, compared to the other compatibility hoops we jump through
based on our own rules, supporting these things ought to be minor.
And as Peter pointed out, we are possibly even playing loose with our
own rules when we drop these things.
I just want SVN to be a better product and churning out new releases
quicker. If dropping APR 0.9.x gets us a better product and shortens
development time, go for it. At the same time, I'd be happy to see us
blow up libsvn_wc and tell users to just deal with it for the same
Received on 2010-03-11 17:04:48 CET