[IronPython] IronPython 2.0.3

[Keith J. Farmer]

Only a week? :)

Keeping m low alleviates some concern for your sanity, but I worry about n, then?


-----Original Message-----
From: Dave Fugate <dfugate at microsoft.com>
Sent: Wednesday, January 06, 2010 11:43
To: Discussion of IronPython <users at lists.ironpython.com>
Subject: Re: [IronPython] IronPython 2.0.3

There's one major benefit of n different IronPython versions though - testing.  Right now, we run all CPy 2.6 tests for every IronPython (2.6) check-in.  If IP 2.6 were to support CPy 2.5 as well, we'd also need to run all CPy 2.5 tests => the check-in times would nearly double.  Don't even get me started on the week of automated tests each major public release of IronPython undergoes:)

Dave

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer
Sent: Wednesday, January 06, 2010 11:21 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython 2.0.3

Yet you end up (worst case)maintaining nm different versions of the entire source, n CPython compats by m NetFX compats?  That's not a great space to be in, and then end-users have to hunt for the IronPython version to use, as seen here.

-----Original Message-----
From: Dino Viehland <dinov at microsoft.com>
Sent: Wednesday, January 06, 2010 10:23
To: Discussion of IronPython <users at lists.ironpython.com>
Subject: Re: [IronPython] IronPython 2.0.3

Keith wrote:
> I was wondering if it might not be better (even possible) to merge the version
> compatibility into a switch, so people would optionally use a targetVersion
> flag or some-such.
> 
> Part of the difference between versions isn't simply language, it's outright
> bug corrections and compatibility with the base DLR, neh?

To a certain extent this is possible - for example it's not too hard to control
the parser based upon version and enable/disable new features.  Also 
controlling what methods are available and a small subset of behaviors is 
pretty easy and  we've done that in the past when we've had options which 
enable a subset of the  next version - 2.6 for example has a -X:Python30 option
which enables some  3.0 features / compatibility.  

But to do this for an entire versions worth of features might be too many 
random checks spread throughout the code base - usually there are plenty of 
small changes in each release which we need to match.  Things like deprecation 
of various features, object.__new__/__init__ changed in 2.6, methods sometimes 
get new arguments, and other little changes like that.  Dealing with all of those 
will be difficult and clutter up the code base making it more difficult to 
maintain.  In some cases we might need to add new features to fully emulate
the old version.

There's also the matter of our own compatibility at the .NET level - we 
constantly need to balance advancing IronPython w/ maintaining compatibility 
w/ existing apps.  Would users upgrade a 2.0.3 app to 2.6 w/ 2.5 compat if 
there are some breaking changes they need to deal with from the C# side?  I 
think a lot of the value in already released versions is their stability
so I'm not sure that having an evolving target which from the Python side
works mostly like the previous version has much value.

Not to mention that it's just plain more work and we already have plenty
to do :)
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com