2009-04-07 19:14:57 Greg Stein napisał(a):
> Everybody:
>
> The current trend of this thread is to follow the plan below. Please
> speak up on your thoughts.
>
> I plan to take action to further this plan, beginning Thursday (that
> provides 72 hours for people to see this thread and provide their
> input).
>
> We are seeing some further failures in the test suite caused by the
> recent unicode changes. I want to give ample time for discussion, but
> also want to get moving on this to avoid problems like we're seeing in
> the tests.
I can't reproduce any test failures, but in r37128 I reverted using of
unicode type in 'subversion/tests' directory.
> On Mon, Apr 6, 2009 at 17:00, Greg Stein <gstein_at_gmail.com> wrote:
> > I think this is an issue that the svn devs need to discuss: what
> > Python versions are required, expected, and supported.
> >
> > I'm going to throw out a strawman here for discussion.
> >
> >
> > End-users
> > - Python is not required to use "core" svn
> > - Python scripts that are part of our distribution bundle
> > - Minimum: 2.4
> > - Supported: 2.x
> > - Possible for some scripts: 3.0
> >
> > Packagers
> > - Python is not required
> >
> > Developers
> > - Python is required: gen-make, test suite, dist packaging, etc
> > - Minimum: 2.4
> > - Supported: 2.x
> >
> >
> > There are two primary goals with my selections above:
> > - Support end-user choices
> > - Reduce maintenance costs
> >
> > It would be nice to support end-user scripts < 2.4, but that increases
> > maintenance costs for us. I believe that 2.4 is a fair balance between
> > user choice and our cost. During the 1.6 release process, we ended up
> > bumping the minimum user version to 2.4. That happened without
> > explicit discussion, so I'm bringing it up for closure on whether that
> > is what we're going to shoot for.
> >
> > Also note that Python 3.0 is *not* part of the Developer toolset. Not
> > even supported. I've been reviewing the changes on trunk for the 3.0
> > compatibility effort with increasing concern. The changes introduce
> > maintenance cost (*), yet with no perceivable benefit to the Developer
> > community. If we confine our support to 2.x, then the dev toolset will
> > be easier to expand, modify, and refine.
> >
> > Thoughts?
> >
> > Cheers,
> > -g
> >
> > (*) where "cost" means awareness and coding specifically for: variant
> > imports, byte/string/unicode/encode/decide changes, syntax concerns,
> > builtin function changes, special methods, etc.
--
Arfrever Frehtes Taifersar Arahesis
Received on 2009-04-09 10:54:05 CEST