[IronPython] IronPython 2.0.3

[Dino Viehland]

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 :)