[Gtk-sharp-list] Re: GTK versions

[Mike Kestner]

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 <mkestner at novell.com>