[IronPython] IronPython 2.0.3

Dino Viehland dinov at microsoft.com
Wed Jan 6 20:47:25 CET 2010


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-bounces at lists.ironpython.com [mailto:users-
> bounces at 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-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



More information about the Ironpython-users mailing list