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

[underdog10 at netcourrier.com]

Hello,

I am the author of a Gtk# app.  The new version will be link to mono 1.1.x and will use Gtk# 2.

Why ?
 1- because i did wish to use the new FileChooserDialog.
 2- to fixed some  gtk# and mono bug.
 3- To use some new feature (specialy event)

But most of the code are from the Gtk# 1 and will stay as is as long as long Gtk# come to stable.

Gtk# 2 is include in the Windows package, and it is working perfectly.
For Linux, it is also working perfectly as long as you install gtk#2 dll.

Keep  in mind that this app is fully multi platform so, it is working on Linux, Win32 and Mac OS X.

I don't know much about gac, but i just want to give my point of view.

Also, i would like to know, if is true:
"Mono 1.0.x use Gtk# 1.0.x, is the stable series of Gtk#, and it binds the GNOME 2.2 platform.
Mono 1.1.x use Gtk# 2.5.x, is the current development series of Gtk#. The target is the Gtk+ 2.6 platform.
So in order to use the new FileChooser dialog, you need to upgrade to mono 1.1 branch which include both Gtk# branch.
Otherwise, you will use the deprecated dialog know as FileSelection dialog."


/Francois



----Message d'origine----
>De: Ben Maurer <bmaurer at ximian.com>
>A: gtk-sharp-list at lists.ximian.com
>Date: Sun, 10 Jul 2005 21:31:45 -0400
>Sujet: [Gtk-sharp-list] Versioning and Unstable Gtk#
>
>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
>
>

-------------------------------------------------------------
NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar...
Web/Wap : www.netcourrier.com
Téléphone/Fax : 08 92 69 00 21 (0,34 € TTC/min)
Minitel: 3615 NETCOURRIER (0,16 € TTC/min)