Mono - rfc for future developments

David Nielsen gnomeuser at gmail.com
Mon Sep 8 19:03:47 UTC 2008


Den 8. sep. 2008 19.48 skrev Paul <paul at all-the-johnsons.co.uk>:

> Hi,
>
> I've just been notified that RC1 of Mono is due to be tagged today at
> some point with RC2 (final) on the 10th. Given the date difference of
> only 2 days, I'll be packaging Mono 2.0 for rawhide.
>
> Future plans.
>
> Currently the mono stack for Fedora is a bit of a mess over the three
> versions available. What I'm proposing for future mono/libgdiplus
> releases is this.
>
> Mono 2.0 is released on the 10th and packaged for rawhide
> Mono 1.9.1 is then released on F9
>
> The stack is then rebuilt to cover gtk-sharp2 et al so that by the end
> of the process rawhide is one version ahead of core.
>
> When Mono 2 becomes 2.9, version 2 is released onto core and so on.
> This, in theory, should kill the problems experienced with the likes of
> monodevelop in core. It also means that core is operating on the stable
> release.
>
> An alternative is that after a couple of months proving on rawhide, the
> rawhide version is pushed to core.


I admit I much prefer the latter method, it keeps the stack roughly the same
accross releases which means our users have access to the latest bug fixes
and a version that is supported by upstream. It also keeps the amount of
code actively supported as low as possible. Aggressively pushing vetted
versions of the Mono stack seems like the wisest plan to me. As a bonus, we
also gain the ability to push the latest and thus often the only supported
version of Mono using apps in our stable repos, something our users expect -
just watch the Banshee mailing list, not only do our users expect the latest
to be available but upstreams first reply to potential problems is nearly
always to install the latest supported version.

Let make use for Rawhide and updates-testing to vet the Mono stack, bodhi
can be used as a metric for when to push updates to stable.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080908/7e42e519/attachment.htm>


More information about the fedora-devel-list mailing list