[mono-packagers] Proposal to require Mono 2.4.2 and GTK# 2.12.9 for MonoDevelop 2.2

Michael Hutchinson m.j.hutchinson at gmail.com
Tue Aug 18 14:22:42 EDT 2009

Hi everyone,

Sorry for the cross-post but this could affect quite a few people.

I'd like to propose that we bump MonoDevelop's minimum GTK# version
requirement to 2.12.9 and the Mono version to 2.4.2. Although these
are fairly recent, they are by no means cutting edge, and they are the
most stable versions currently available. These requirements would
affect the upcoming MonoDevelop 2.2. release, which is currently
scheduled for the end of October:

Rationale for requiring Mono 2.4.2:

* 2.4.x is a long-term stable Mono branch
* The Mono debugger is *much* more usable in 2.4.x
* MonoDevelop 2.0 required Mono 2.0, but trunk already requires Mono
2.2 because we use some functionality that doesn't work/compile on
2.0. Continuing to support 2.0/2.2 has a nontrivial maintenance cost.
* There are some runtime issues in 2.2 that cause startup hangs. These
are improved in 2.4, and the complete fix is expected to be backported
from Mono 2.6 to the 2.4 branch.
* MonoDevelop 2.2 will have the ability to target parallel runtimes,
so developers wishing to develop against older releases can use
parallel Mono installations.

Rationale for requiring GTK# 2.12.9:

* GTK+ 2.12 is now two years old, and very widely available.
* We were primarily supporting GTK+ 2.8 in order to run on SLED10, and
SLED 11 has now been available for a while.
* Switching to 2.12 would enable us to tidy up a lot of hacks and
workarounds, and move to some nicer APIs (e.g. tooltips), thus
lowering our maintenance burden.
* Requiring the 2.12.9 bugfix point release would fix quite a few GTK#
issues, and would improve stability, particularly in Stetic.
* MD can still be used to target older GTK versions, so this is only a
requirement for developers using MD, not *their* users.

In summary, upgrading dependencies will help us to ensure that
developers using MonoDevelop get the most stable experience possible,
while also reducing the maintenance burden. MonoDevelop 2.0 will of
course continue to be available for people who can't meet these

If you have good counter-arguments please put them forward ASAP.


Michael Hutchinson

More information about the mono-packagers-list mailing list