Den 8. sep. 2008 19.48 skrev Paul <paul@xxxxxxxxxxxxxxxxxxxxxx>:
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
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
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
