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? Thanks, Martin On 22 October 2014 22:18, Miguel de Icaza <mig...@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 <monofo...@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 <mig...@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.koeplin...@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@lists.ximian.com >>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>> >>> >>> >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list@lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >>> >> >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
