Mono - rfc for future developments

[Michel Salim]

2008/9/8 David Nielsen <gnomeuser at gmail.com>:
>
>
> 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.
>
I concur; the Mono stack seems to be monotonically (pun alert!)
increasing in usability, that the benefits of maintaining a single
Mono major version across our supported releases outweigh the
stability concerns.

Would we have time to get 2.0 into F-9, and rebuild the Mono stack
there, or do we need an interim release of currently-FTBFS Mono
packages? (thinking of Monodevelop here. Wouldn't want it blacklisted)


-- 
Michel Salim
http://hircus.jaiku.com/