[Mono-list] [Mono-dev] The Mono 1.0 profile.

[Marek Habersack]

Gert Driesen wrote:
>> -----Original Message-----
>> From: mono-list-bounces at lists.ximian.com
> [mailto:mono-list-bounces at lists.ximian.com] On Behalf Of Miguel de Icaza
>> Sent: dinsdag 21 juli 2009 17:50
>> To: Gert Driesen
>> Cc: 'mono-list'; 'Mono Announce'; 'mono-devel-list'
>> Subject: Re: [Mono-list] The Mono 1.0 profile.
>>
>> Hello Gert,
> 
> Hello Miguel,
> 
>>> Will you be removing all 1.0 specific code (paths)?
>>> Will support for building the net_1_1 profile be removed altogether (or
> will
>>> you just need to opt-in)?
>> Yes, I would like to do that: remove all the ifdefs for net_1_1 on post
>> Mono 2.6 releases, and remove all the tests for 1.1 compatibility as
>> well.
> 
> Personally, I think we'll waste more cycles on this than that it will bring
> benefit.
I disagree. 1.1 is a) mature enough to be moved to a separate location (in our case 2.4/2.6) to be 
maintained there should a fix be needed, b) slowly being phased out of real projects (not to mention 
new developments). Us having to carefully examine 1.1 code when we fix 2.0 bugs or add new code is 
really time consuming and unnecessary.

> I'm sure there are more urgent matters.
> I know the ifdefs are a mess, but we'll have them anyway (if we do not only
> want compatibility with MS's latest and greatest).
Changes between 2.0 and 4.0 are not as dramatic as between 1.0 and 2.0 - they are mostly new APIs, 
or old internal APIs made public. We'll get rid of a real ton of #ifdefs, not to mention separate 
directories containing different code for 1.1 and 2.0 (like System.Web's configuration and session 
stuff)

>>> Will you discourage packagers to include the net_1_1 profile?
>>> I understand that Novell itself cannot continue supporting all profiles,
> but
>>> I think you should at least allow the community to continue this.
>> My feeling is that we should come to a place where you can have two Mono
>> runtimes installed, an older one to run the 1.0 runtime, and another one
>> to run 2.0 and 4.0.
> 
> Are you planning on creating a branch that can still be actively worked on
> by/for those that want to maintain the highest level of compatibility with
> .NET 1.1?
 From what I understand, 2.4 will is a long maintenance release and 2.6 will also be around with the 
latest 1.1. It's not a problem to commit a fix from time to time (rather unfrequently) to one, or 
even both, of those branches. The effort of doing it is much less that having to constantly cope in 
current code with legacy stuff.

> I'm not sure if anyone is even interested in this. If there is, then I
> assume they will even want to create new (bugfix/security fix) releases.
This is part of long term maintenance releases anyway, no added effort here. Personally, I don't 
have any problem with backporting an fix to the maintenance branches once or twice a year.

>> The issue is not only a problem with build times taking longer for each
>> developer, they also take longer one each build bot, it almost doubles
>> the test suite run times, and it wastes developer time (Novell or
>> otherwise) making sure that we do not break the 1.0 profile.
> 
> Sure, but you could just make the 1.0 profile opt-in.
That wouldn't change anything for developers, it would only limit the build/test time. The biggest 
issue here, IMHO, is the wasted developer time.

> And perhaps only run the build bot test for that profile once a week (and
> leave it up to contributors to deal with it).
If you have a good, proven release like 2.4 or 2.6 with stable runtime and class libraries, even 
that won't be necessary - you just know you have to run the tests for 1.1 only if a change is made 
to either the runtime or the class library. It is really more efficient that way.

>> With the introduction of the 4.0 APIs with a new mscorlib we will end up
>> in a situation where every check in has to be tested and compiled
>> against 3 versions.   It is an amount of work that is slowing Mono down
>> as a whole.
> 
> I understand, and making the 1.0 profile opt-in would deal with that.
> You should also make it clear that the 1.0 profile is no longer endorsed by
> Novell.
Then why leave it in the source code for the newer releases?

> 
>> I rather invest in finding creative ways of packaging and installing two
>> monos in parallel for those that want to have 1.0 based apps.
> 
> Is this something that you will do or want to do ? ;-)
> 
> Note that I'm not opposed to making the 1.0 profile a second-class citizen,
> but I consider removing it altogether a radical change.
It will still be available and maintained at least for quite some time, so it's not removed per se.

marek