On Tue, Jan 13, 2009 at 12:30, Blair Zajac <blair_at_orcaware.com> wrote:
> Paul Burba wrote:
>> On Mon, Jan 12, 2009 at 4:41 PM, Blair Zajac <blair_at_orcaware.com> wrote:
>>> Paul Burba wrote:
>>>> On Fri, Jan 9, 2009 at 10:23 PM, David Glasser <glasser_at_davidglasser.net>
>>>> wrote:
>>>>> I'm pretty sure we decided to do this several times already. Search for
>>>>> mail
>>>>> from me about it...
>>>>>
>>>>> --dave
>>>> Dave found this other thread he mentioned above:
>>>> http://svn.haxx.se/dev/archive-2007-10/0867.shtml
>>>>
>>>> Blair, in that thread you objected to 2.4 at the time because:
>>>>
>>>>> I suggest bumping to 2.2 since RHEL 4, which is still in a lot
>>>>> of places, is on 2.3. To have to build Python 2.4 or greater
>>>>> just to test svn on RHEL 4 would be a pain.
>>>>>
>>>>> So bump to Python 2.2 but include subprocess.py with the svn test suite.
>>>> Blair, does your previous objection still hold today?
>>> How much work is it to support 2.3 in the current code? I just saw one
>>> commit you had r35193.
>>
>> Hi Blair,
>>
>> Probably not that much, after r35193 I can successfully run the tests
>> with 2.3.5, though I still can't do a fresh rebuild of Subversion with
>> 2.3.5 (I still think that is probably a minor problem, though I
>> haven't tried to fix that since I have only been interested thus far
>> in getting the buildbots working and supporting running the tests in
>> parallel on my own Windows box).
>
> I updated to r35212 and setting PATH=/usr/bin:/bin and PYTHON=/usr/bin/python on
> our Centos 4 box everything worked fine.
>
>> So it mostly comes down to the fact that we are trying to maintain the
>> two different code paths for 2.4+ and < 2.4 and does the effort of
>> doing so justify the benefit of supporting < 2.4...
>
> I think we need to maintain compatibility with tools that build Subversion on
> recent OSes. The fix in r35193, if not applied, would require the Subversion
> packager to build Python and then Subversion. I think overall it's probably
> less effort for us to do this work in one place then require anyone on an older
> OS to build Python.
We're expecting effort to support Python < 2.4, with no measurable
return on our work. We don't know that anybody *needs* to use old
versions.
We should just switch to Python 2.4. The requirement is only for devs
and packagers. NOT for users. This is quite a small group of people,
relatively speaking. I think we can expect any of these people to have
Python 2.4 handy.
At this point, we haven't heard anybody come up with a scenario for <
2.4, so let's make the switch.
Cheers,
-g
Received on 2009-01-13 22:03:50 CET