On Tue, 2005-11-08 at 19:13 +0000, José Alexandre Antunes Faria wrote: > Problems. > 1. gtk 2.2 is hidden under gtk-sharp 1.0 > 2. gtk 2.4, 2.6 and 2.8 is hidden under gtk-sharp 2.0 > 2. released gtk-sharp 2.0 is limited by gtk 2.4
The second #2 is likely to change in the next couple months. Our plan is to package 2.7.x releases for the current suse release as soon as I get 2.7.1 released, probably this week. > So now every developer who wants to target 2.6 or 2.8 has to custom > compile. Not a huge hardship for a developer, and in the 2.8 case, not for much longer. If you want to package 2.6 for platforms that can support it, fine, but we are considering it a source-only release and skipping from 2.4 to 2.8 for our packaging effort. I don't personally see a lot of value in targeting 2.6 if 2.8 is just around the corner. You probably either want maximum goodies (2.8) or maximum market penetration (2.4). > It should be possible to have them all installed. > Even for final clients. If you are talking about for runtime users only, there is no point to having 2.4 installed next to 2.6 or 2.8. 2.8 provides policy assemblies to run applications which were compiled against the 2.4 assemblies. Having all of them parallel installable from packages is problematic. Look at the current 1.0.x to 2.x migration. In order for an application to be compiled against 2.x, changes must be made to the make/compilation system. You have to patch previously released frombulator-1.0.3 Makefiles to make it compile without a gtk-sharp-1.0.x installed because of the change in .pc file name, even if you have no intention of using newly added/exposed API. With the 2.4 -> 2.6 -> 2.8 migration path, this won't be the case, because one Makefile accessing gtk-sharp-2.0.pc via pkg-config or mcs -pkg: will work against all of them. We have some experience with the suckiness of parallel-installability. Ask Ben or Wade about how much fun it is to patch existing released Gtk# versions to make them compile against the gtkhtml pc file of the month. I don't want users and packagers to have to deal with the same pain for Gtk#. > Besides we are needing an entry fork on monodoc, how do we feed in > documentation for more fresh features. I know most are the same. We already identify what version an API element was added using the <since> element in the docs. monodoc annotates the docs accordingly. > What I propose is to have different gtk-sharps and to make things > simpler, I would advise something like: > > 1. gtk-sharp 2.2 -> gtk 2.2 This is 1.0.x. It is not likely that we will renumber that stream, especially for such cosmetic reasons. It is unlikely to be released again unless we find some horrifying bug, and nobody has found one yet. > 2. gtk-sharp 2.4 -> gtk 2.4 > 4. gtk-sharp 2.6 -> gtk 2.6 > 5. gtk-sharp 2.8 -> gtk 2.8 This is exactly what we have, with the odd releases being unstable. -- Mike Kestner <[EMAIL PROTECTED]> _______________________________________________ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
