[Gtk-sharp-list] Versioning and Unstable Gtk#

[Ben Maurer]

Hey guys,

I've been working with tseng, our fearless Ubuntu packager on packaging
Gtk# 2 apps. It looks like we are pretty clearly not going to be api
frozen soon enough to make it a good idea to ship Gtk# 2 in the GAC.

So, I suggested that we include a pre-release gtk# in the private bin
path for gtk# 2 apps (muine and monodevelop). However, when I was
thinking about this, I realized we had a little problem.

As documented on http://tinyurl.com/3y73k, the runtime loads assemblies
from the GAC before it does private path probing. This is done for
performance reasons (it is more likely that code gets shared between
processes. Also, for non-gac'd strong named assemblies, the entire file
has to be read from disk to check the signature. With that gac this is
done at install time).

Right now, we ship pre-release gtk# assemblies with versions 2.4.0.0.
So, if somebody installs an ubuntu with Gtk# 2 (a pre release) in md's
private bin path, and later (after we release gtk# 2), installs the
final .dll files into the gac, when monodevelop is launched, the
final .dll files will be found by the runtime. However, these may have
api differences, and thus break MD.

I can think of three ways to make this situation not break:

1. Use different version numbers for pre-releases
--------------------------------------------------

In this solution, the .dll version of Gtk# would change on each
pre-release. Thus, the MD that is installed with ubuntu would bind to
2.3.4.0 (eg). When the user installs 2.4.0.0 in the gac, the older
assembly will still be loaded by the runtime.

For the final release, and all subsequent stable releases, the .dll
would have the version 2.4.0.0

Pros:
      * Easy for packagers (they just move the files into the bin path)
      * Makes packages of applications that depend on unstable gtk# less
        likely to break (because the rpm will code a dependency to the
        exact gtk# version and refuse to upgrade to newer pre-releases)

Cons:
      * Small pain for people working from svn: multiple copies of gtk#
        will get installed in their GAC.

2. Use a different version number for each release
---------------------------------------------------

Same as above, except that we continue the policy through stable
releases. We will have assemblies 2.4.1.0, 2.4.2.0

We would use publisher policies to make sure that no matter what stable
version of gtk# a program was built on, it would run on all others.

Pros:
      * In theory, would allow parallel installation of stable gtk#
        versions. Also, makes it easy for an application to demand a
        specific version of gtk#.

Cons:
      * Makes rpm dependencies a bit of a pain (the automated script
        that searches for dependencies would probably have trouble with
        this).

3. Force people shipping unstable versions of gtk# to rename the
assembly
-----------------------------------------------------------------

Probably the easiest way for a packager to do this would be to sign gtk#
with a different key. In the eyes of the runtime, this would mean that
the gtk#'s we ship would not match the library the application was
looking for. Thus it would use the one on the private path.

Pros:
      * Easy for us (no effort involved)

Cons:
      * Harder for packagers (they have to build custom gtk# versions)
      * Annoying for plugins (any MD plugin would have to compile with
        the custom gtk#)
      * Doesn't allow us to take advantage of the configuration options
        offered by the runtime

-- Ben