[Mono-dev] Heads up: Elimination of the 2.0 and 4.0 profiles

Martin Thwaites monoforum at my2cents.co.uk
Fri Oct 24 16:34:27 UTC 2014

Hi Miguel,

I think my preference would be to have the 3.x.x series continue (as
security fix only) with all the profiles, and essentially have it be a
legacy branch.  Then have the 4.x.x series by a .NET 4.5+ only code base.
I think it should continue if people are willing to support it, but the
contributors who don't want to have to support it (or don't have the time
to implement hacks for it) don't have to.

>From a communication perspective it would be easier to get across saying
that "From mono 4.0 onwards, we only support the 4.5 profile" rather than
3.11.x onwards as it's not as easy to remember which 3.x number it was when
it stopped.  A decision and a change like that does really feel "major" and
therefore warrant the change.

The other question I have is around the linux distros that ship mono as
standard (I think Ubuntu does).  Do you perceive this having an affect on
them, i.e. they will never ship 4.0 as it doesn't cater for .NET 2.0
applications and there are some core pieces that rely on it?


On 22 October 2014 22:18, Miguel de Icaza <miguel at xamarin.com> wrote:

> Hey,
> Mhm, that is a good idea.   Will think about it.
> Right now we were just planning on calling the next one Mono 3.12.   But
> perhaps the time has come for a nice bump!
> Miguel
> On Wed, Oct 22, 2014 at 4:21 PM, Martin Thwaites <monoforum at my2cents.co.uk
> > wrote:
>> Hi Miguel,
>> Would you be looking at calling this Mono 4.0? Not that it makes any
>> difference really, it just seems there's been a lot of improvements in
>> recently, and an announcement of a new version me give some renewed
>> interest.
>> Thanks,
>> Martin
>> On 22 October 2014 21:10, Miguel de Icaza <miguel at xamarin.com> wrote:
>>> Hey Alex,
>>> It is very repetitive work, so what I wanted to do was to write a perl
>>> script to remove the *obvious* ifdefs.   The tool would remove only those
>>> that match the following criteria (more or less):
>>>    - Remove toplevel #if NET_2_0 with the final #endif
>>>    - Only remove those that contain those preprocessor directives
>>> And then have a human do the more fine-tuned approach.      There are a
>>> couple more defines that I remember could be automated, but I would love to
>>> have this in the form of a script.
>>> I am afraid of applying a patch like that blindly, because there are no
>>> exact guarantees of what happened without reviewing the whole file.  So a
>>> script with the invariants would take a lot of my nervousness out.
>>> Also, when I did it once, I had a setup where I rebuilt the assemblies
>>> and compared the output.  This would ensure that removal of ifdefs did not
>>> change the resulting binaries.
>>> On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger <
>>> alex.koeplinger at outlook.com> wrote:
>>>> Sounds like a good thing ;-)
>>>> I've got a branch in my fork where I removed the NET_2_0 ifdefs:
>>>> https://github.com/akoeplinger/mono/compare/remove-net20-ifdefs,
>>>> @kumpera
>>>> told me a while ago that removing the 2.0 profile is on the horizon
>>>> when I
>>>> asked about why the ifdefs are still there.
>>>> I refrained from making a PR so far because it is quite huge, do you
>>>> think
>>>> now would be a good time?
>>>> -- Alex
>>>> --
>>>> View this message in context:
>>>> http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664325.html
>>>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>>>> _______________________________________________
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list at lists.ximian.com
>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141024/5a887673/attachment.html>

More information about the Mono-devel-list mailing list