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 _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
