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-boun...@lists.ironpython.com [mailto:users-boun...@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 <di...@microsoft.com> Sent: Wednesday, January 06, 2010 10:23 To: Discussion of IronPython <users@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@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com