https://bugzilla.novell.com/show_bug.cgi?id=353597
User [EMAIL PROTECTED] added comment https://bugzilla.novell.com/show_bug.cgi?id=353597#c1 Gert Driesen <[EMAIL PROTECTED]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED] --- Comment #1 from Gert Driesen <[EMAIL PROTECTED]> 2008-01-14 05:20:28 MST --- In my (humble) opinion, these should all be installed in the 3.5 directory. Users should be aware what framework version of .NET or Mono "Profile" they're using, and choose explicitly to target a specific version instead of seemlessly rolling into a new version. I think there probably is already enough confusion with regards to our version scheme (when compared to MS .NET). THe only constant right now was that our "profiles" matched a given framework version (not CLR version). So I'd vote against combining multiple .NET framework versions in a single mono profile. In fact, I think the way our toolset is named and packaged could have been better. We currently have a mixture of unique names (mcs <-> gmcs), and version suffixes (al <-> al2). While other tools are even only available for a given profile version (eg. xsd). If we had at least a complete set of tools available for each profile, then we could have separate distributions for each profile, or at least have clearly defined dependencies. Even if the 2.0 and 3.5 profile use the same CLR and core system assemblies, the toolset of both profiles is different (new changed/functionality, new tools, ...). If API compatibility with MS is considered "important", then so should tool compatibility be. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
