Ok, I'd better move to the trunk then... So if the trunk and the 1.1.x branch have grown so far apart, wouldn't it be useful to create a tag from the trunk once a month or so to mark a stable build? From the messages on this list, I get the impression that trunk builds are broken once in a while, so working on head revision is probably not a good idea when you are trying to develop a uDig add-on, and not uDig itself.
Incidentally, I always assumed that the "RC" in "1.1-RC14" stands for "Release Candidate", so I was wondering when the magic 1.1.0 release would finally arrive. Now I get the impression that the 1.1.x branch is simply your stable branch and that you provide bugfix releases in regular intervals. Maybe it's just a matter of personal taste and habit, but I think it would be more intuitive to call these stable releases 1.1.14, 1.1.15 etc. and to start creating release candidate tags 1.2RC1, 1.2RC2, ... from the trunk until the trunk gets stable enough to cut a 1.2.0 release and a 1.2.x release branch while the trunk moves ahead towards 1.3. Is there a particular target in terms of functionality or timeline for a release 1.2? Regards, Harald > > > > So far, I've been working with 1.1RC14, and I don't really > know what's > > going on the trunk. The only thing I need is a kind of stable and > > reproducible basis. A particular revision number of the > uDIG trunk and > > the appropriate Geotools branch would probably be enough. I see a > > 2.6-SNAPSHOT in the Geotools dependencies which worries me a bit. I > > don't want to work against a moving target... > > > > The wiki page mentions a 1.2.x branch which I cannot find. > Is that the > > trunk now? > > Yes. > > The choice depends on your time frame and stability needs but > I would strongly recommend trunk if you can stomach the rough start. > > 1.1 is based on geotools 2.2 which is from a long time ago. > However, this is stable in that none of its dependencies are > changing so if you can get it working it will stay in that > same state for a long time. > > trunk/1.2 is based on geotools trunk (essentially 2.5) and > uses eclipse > 3.4 both of which have improved a good amount. Jesse is > ironing out the issues with SDK generation so trunk promises > to be a more flexible release as well as being more up to date. > > As for figuring out the OSGI stuff, it would be fantastic to > have someone give us a better understanding of that framework > and build a workaround for the one massive library bundle. > > --adrian > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel > ******************************************* innovative systems GmbH Navigation-Multimedia Geschaeftsfuehrung: Edwin Summers - Kevin Brown - Regis Baudot Sitz der Gesellschaft: Hamburg - Registergericht: Hamburg HRB 59980 ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. ******************************************* _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
