| Article: |
Porting a Project from Visual Studio .NET to Mono | |
| Subject: | Try a more modern version... | |
| Date: | 2005-06-14 00:17:06 | |
| From: | schwuk | |
|
I know you were using the version most easily available to you, but I'd fully recommend trying a more modern version of Mono. The project maintainers themselves recommend the use of the 1.1 development branch over the 1.0 stable branch as this is now where all effort is concentrated.
|
||
Showing messages 1 through 2 of 2.
-
Managers will disagree...
2005-06-14 14:18:58 kfarnham [Reply | View]
-
Managers will disagree...
2005-08-30 14:11:01 migueldeicaza [Reply | View]
Well, a manager would probably pick the officially supported version of Mono, and that version happens to be 1.1.8.
Thats the official position of the Mono team at Novell.
If the manager cared about this, he would know a few things: that Mono 1.1.x has four times as much tests built into it, and that Mono 1.1.x has gone through Novell's hardening process which includes various flavors of testing for use in its own client and server products and have passed rigurous tests on the Novell Superlab having hundreds of mono client applications hitting Mono servers and ironing out all the bugs.
Mono 1.0.x was retired due to this kind of testing and that is why every user is encouraged to use the 1.1.x series.
The 1.1.x code base is hardened now in branches, and when the code is hardened and tested it is landed.
Miguel.





The issue is stability. A company that is experimenting with Linux might chose the Debian platform because of it's slow and careful release cycle, which yields the reliability Debian is known for. With respect to Mono, the assumption is going to be that the most stable Mono on Debian will be the version that is available using the package manager on the most stable Debian release.
In "selecting" Mono Version 1.0.5 for the article, I duplicated the decision that a development manager likely would have made for porting an application that has some mission criticality. For operational applications that are integrated into your daily business activity, you don't immediately jump to the latest development version. You can't afford to be so experimental. Instead, you look for a version that has gone through a reasonable testing cycle, where the most significant and blatant bugs have been addressed -- even if that version is missing some nice features that are available in later releases.
So, from a Development Manager's point of view, is the article "shamefully out-of-date"? I don't think so.