[Mono-list] The Mono 1.0 profile.
gert.driesen at telenet.be
Tue Jul 21 15:50:48 EDT 2009
> -----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,
> > Will you be removing all 1.0 specific code (paths)?
> > Will support for building the net_1_1 profile be removed altogether (or
> > 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
Personally, I think we'll waste more cycles on this than that it will bring
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).
> > Will you discourage packagers to include the net_1_1 profile?
> > I understand that Novell itself cannot continue supporting all profiles,
> > 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
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.
> 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.
And perhaps only run the build bot test for that profile once a week (and
leave it up to contributors to deal with it).
> 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
> 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.
More information about the Mono-list