Dropping .NET 2.0 Support for IronRuby

Ruby IronRuby
1

Right now, the plan is for IronPython to drop support for .NET 2.0 and
be .NET 4 only for the 3.0 release (which is probably still a year or
more away). Are there any similar plans for IronRuby? IP can drop 2.0
support without impacting IR at all (I think), but if there plans to
drop it from IR as well we can trim up the repository somewhat (in
particular, the DLR inner ring could be removed and live in the Mono
tree, or something like that).

  • Jeff
2

I’d be fine with dropping support for Desktop v2.0. We need to support
Silverlight 3 builds though so that we continue running on Windows Phone
7. This essentially means we can’t get rid of the inner ring just yet.
Do you consider supporting IronPython on Windows Phone too? The only
work that’s needed there is to interpret call-sites instead of compiling
them. Some of them already do so but there are others that don’t. Plus
you’d need a bit refactoring to avoid referring Ref.Emit types in common
code paths.

Overall I don’t think dropping v2.0 build buys us that much if we need
Silverlight 3 build anyways. Do you experience problems or excessive
amount of work supporting v2.0 builds?

Tomas

3

On Wed, Apr 6, 2011 at 4:00 PM, Tomas M.
[email protected] wrote:

I’d be fine with dropping support for Desktop v2.0. We need to support
Silverlight 3 builds though so that we continue running on Windows Phone 7. This
essentially means we can’t get rid of the inner ring just yet. Do you consider
supporting IronPython on Windows Phone too? The only work that’s needed there is
to interpret call-sites instead of compiling them. Some of them already do so but
there are others that don’t. Plus you’d need a bit refactoring to avoid referring
Ref.Emit types in common code paths.

It’s a pretty common request, but no one has stepped up to do it yet,
and it doesn’t interest me personally. I don’t want to rule it out,
though. I think we’d similar work to run on MonoTouch as well.
However, we could restrict that to the 2.7 line until WP gets a proper
Silverlight 4/CoreCLR runtime.

Overall I don’t think dropping v2.0 build buys us that much if we need
Silverlight 3 build anyways. Do you experience problems or excessive amount of
work supporting v2.0 builds?

We’re still going to support them for 2.7, and 2.7 will be around for
a long time. For 3.0 I doubt I’ll do anything to actively break 2.0
support, but testing against it won’t be done on a regular basis, and
if it breaks, and no one steps up to fix it, it’ll stay probably stay
broken.

  • Jeff
4

I think having the V2 build there but not actively tested works fine.
Anybody who wants to use the latest IPy 3.0 build on V2 could submit a
patch that fixes v2 specific issues if there are any.
What about “officially” declaring we don’t support V2 but keep the
infrastructure in place and not intentionally remove v2 specific code.
Sounds good?

Tomas

5

On Wed, Apr 6, 2011 at 4:19 PM, Tomas M.
[email protected] wrote:

I think having the V2 build there but not actively tested works fine. Anybody
who wants to use the latest IPy 3.0 build on V2 could submit a patch that fixes v2
specific issues if there are any.
What about “officially” declaring we don’t support V2 but keep the
infrastructure in place and not intentionally remove v2 specific code. Sounds
good?

Sounds good to me. I hate to invoke the “It’s OSS; if you want it, you
do it” rule, but this seems like an appropriate place to do so.

  • Jeff