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

[Carlos Alberto Cortez]

Hey,

Currently I'm working in Publisher Policy support, which could help to
solve this, since it could redirect the reference from gtk 1.x to 2.x.

I don't know if this could help the way you want. Anyway, I will be
sending the patches today night.

Carlos.

El dom, 10-07-2005 a las 21:31 -0400, Ben Maurer escribió:
> 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
> 
> _______________________________________________
> Gtk-sharp-list maillist  -  Gtk-sharp-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list