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

[Ben Maurer]

On Sun, 2005-07-10 at 18:59 -0700, Todd Berman wrote:
> On Sun, 2005-07-10 at 21:31 -0400, Ben Maurer wrote:
> > 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.
> 
> This is the worst solution you could ever come up with to this problem.
> 
> 
> I have an idea. How about ubuntu ships what is the latest release at
> that time and we go from that. If people just stick to the stuff in
> ubuntu's repo, then they are fine, and if people start using the latest
> gtk#, then obviously they are going to need to use the most recent
> version of its various consuming applications. Such is the suck of
> riding along the newer development lines.

It'd be best that Gtk# (and mono) not obtain a reputation as fragile and
for causing breakage on upgrades.

Shipping with a non-api stable version of a library -- especially one
that has the same name as and is not parallel installable with the
stable version -- in the gac *WILL* cause confusion at best and breakage
at worse. Problems here may be hard to detect -- Applications compiled
against the stable gtk# 2 will happily load the beta version that will
ship with ubuntu. When a method can't be found, the user will get a
strange runtime assert. 

> I dont really see any of this as a 'big' deal, Ubuntu will ship another
> release in 6 months.

Yeah, lets just allow stuff to silently break because we don't want to
deal with the version policies we promote
(http://www.mono-project.com/Assemblies_and_the_GAC).

> All 3 of your hackish solutions add *permanent* issues we will have to
> deal with, where as just dealing with the suck, the issues go away in 6
> months.

I'm not sure how these add permanent issues. My first suggestion
(changing the version only on unstable releases) is *exactly* the same
as what we are doing now once we do a stable release. Nobody should
expect a binary built against a beta version to work on the final
version, this just strictly enforces that. The second solution has some
permanent ramifications for gtk#, however, these may be things we
actually want, and is much more inline with what MSFT seems to promote.
My third solution is a bit more radical.

> I am not confident that we will see another MonoDevelop release until
> the stable gtk# release regardless, so 0.7 is what would be current at
> that time anyway.
> 
> Just as an aside, no MonoDevelop that ships a internal gtk# or a weirdly
> versioned gtk# through any means will ever be supported. As in, don't
> file your bugs with us, because that is not a sane way to deploy any
> application, especially a development environment.

Well, if MD loads gtk# from its private bin path, there is no reason it
should ever know the difference. Of course, this makes it hard for MD to
build gtk# 2.0 apps. However, I think it would be silly for us to ship
Ubuntu with an MD that encourged people to build gtk# 2.0 apps -- the
apps that somebody built with that version would very likely break on
the final gtk#. IMHO, the MD that ships with ubuntu should have no pre
defined projects for gtk# 2.0 apps -- regardless of if a beta of gtk#
2.0 is in the gac. It should promote the use of gtk# 1.0.

-- Ben