Unfortunately both kinds of confusion cannot be avoided through a single
version number.
The only way to express a feel that Mono 1.x is getting very close to
complete .NET 2.0 compatibility (where it is not already) would be to
number Mono as 1.8.x / 1.9.x as it gets really close to feature
On 02/11/2007, Engler, Eric [EMAIL PROTECTED] wrote:
If we could just bundle a micro-mono for Windows into our
distribution, we wouldn't have to worry about testing on two
platforms (mono and MS .net) and the installation package
would be smaller and faster.
Is mkbundle an option? It
Thomas Wiest escribió:
Ernesto wrote:
Euan MacInnes wrote:
I would suggest that, rather than one version, Mono should split up
it's packages differently.
I have to agree. If we are talking about a on size fits all Mono
distribution, no version number can be too descriptive.
On 31/10/2007, Euan MacInnes [EMAIL PROTECTED] wrote:
This is also better for more lightweight environments and applications, i.e.
casual games and Windows CE devices which have download/space restrictions,
and I'd rather not get into custom forks of the mono build to cope with
those
Euan MacInnes wrote:
I would suggest that, rather than one version, Mono should split up
it's packages differently.
I have to agree. If we are talking about a on size fits all Mono
distribution, no version number can be too descriptive.
My guess is that numbering Mono as either 1.x or 2.x
Ernesto wrote:
Euan MacInnes wrote:
I would suggest that, rather than one version, Mono should split up
it's packages differently.
I have to agree. If we are talking about a on size fits all Mono
distribution, no version number can be too descriptive.
Exactly, so maybe we
Speaking completely selfishly, this would be great for me. We're
working on a cross-platform C# app and oddly, the hardest part of the
installation is ensuring that *Microsoft's* .net is installed
properly. If we could just bundle a micro-mono for Windows into our
distribution, we wouldn't
I think the only way to minimise confusion in the developer population
that does not keep up-to-date with the details of development on Mono
is to let at least the major version track full .NET compatibility.
That is, do not move to v2.x.x until at least .NET 2.0 can be fully
supported, do
Hello,
I tried out the tool and aside from some typical path issues, the app
ran great. Kudos to the WinForms developers! Is there any way to get
MoMA to do some Cecil magic and fix path issues? 2 Points for
evaluate, but you really get extra credit for remediate!
I guess we get the two
Hi Miguel,
In the case of nunit, if you run say nunit-console that
will load the 1.0 runtime, and if that later tries to load an
assembly that was compiled with 2.0 it will load it, but it
will later fail when the assembly tries to reference 2.0 features.
FWIW, the next NUnit won't work
I think the only way to minimise confusion in the developer population
that does not keep up-to-date with the details of development on Mono is
to let at least the major version track full .NET compatibility. That is,
do not move to v2.x.x until at least .NET 2.0 can be fully supported, do
not
I agree.
Jerry van Leeuwen wrote:
I think the only way to minimise confusion in the developer population
that does not keep up-to-date with the details of development on Mono
is to let at least the major version track full .NET compatibility.
That is, do not move to v2.x.x until at least
On 10/30/07, Jerry van Leeuwen [EMAIL PROTECTED] wrote:
I think the only way to minimise confusion in the developer population that
does not keep up-to-date with the details of development on Mono is to let
at least the major version track full .NET compatibility. That is, do not
move to
On the other hand, just today I received an email with this text:
It is C# based (some of the code uses .Net 2.0 features so it's
not mono-ready code). The editor .
I tried out the tool and aside from some typical path issues, the app ran
great. Kudos to the WinForms
Am 30.10.2007 um 00:33 schrieb Jerry van Leeuwen:
I think the only way to minimise confusion in the developer
population that does not keep up-to-date with the details of
development on Mono is to let at least the major version track
full .NET compatibility. That is, do not move to
On 31/10/2007, Andreas Färber [EMAIL PROTECTED] wrote:
The problem with that Microsoft-ish numbering scheme and exactly
those people is that they might then start thinking they need Mono
2.x and Mono 1.x alongside just like Microsoft .NET Frameworks, and
start unnecessarily messing around with
[reply is inline]
On Wed, 2007-10-31 at 14:38 -0400, Avery Pennarun wrote:
On 31/10/2007, Andreas Färber [EMAIL PROTECTED] wrote:
The problem with that Microsoft-ish numbering scheme and exactly
those people is that they might then start thinking they need Mono
2.x and Mono 1.x alongside
On 31/10/2007, Mirco Bauer [EMAIL PROTECTED] wrote:
Indeed. For what it's worth, I think either Debian or Ubuntu invented
some screwy system of installing two versions of the mono libraries
side by side,
Mono ships 2 different versions of all base-class-libraries, one for 1.0
and one for
installation size, however backwards compatibility with the
bulk of the market (Windows 95/98) has been dropped.
Date: Wed, 31 Oct 2007 16:14:10 -0400 From: [EMAIL PROTECTED] To: [EMAIL
PROTECTED] CC: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev]
Mono version numbering On 31/10/2007
19 matches
Mail list logo
