The other thing is it's not quite n * m as m for 2.5 is only 1, and it's only 2 for 2.6. Eventually it'll go back down to 1 again.
> -----Original Message----- > From: users-boun...@lists.ironpython.com [mailto:users- > boun...@lists.ironpython.com] On Behalf Of Dave Fugate > Sent: Wednesday, January 06, 2010 11:43 AM > To: Discussion of IronPython > 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-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 _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com