Hi All, Okay I've just done a big OWSLib commit and merged all the code from the soswfsbranch into the trunk.
http://trac.gispython.org/lab/changeset/1317 One of the CSW tests (csw_devgeo.txt) is failing. Also I couldn't find any tests for SOS - Tom, do you have any code you can convert into a doctest? Also I agree with Sean that we probably need to have an interface sanity check - I haven't really paid any attention to it during this merge. Cheers Dom On Wednesday 08 July 2009 18:01:50 Kralidis,Tom [Ontario] wrote: > I say let's release and get it out there. > > ..Tom > > > > -----Original Message----- > From: [email protected] on behalf of Sean Gillies > Sent: Wed 08-Jul-09 05:42 > To: gispython.org community projects > Subject: Re: [Community] OWSLib release strategy? > > On Jul 7, 2009, at 1:15 PM, Dominic Lowe wrote: > > Hi all, especially OWSLib commiters, > > > > There's a lot of new stuff that has gone into OWSLib recently - > > some of it is > > in the trunk and some is lurking in a branch yet to be merged with > > the trunk. > > Most of it is still work in progress. > > > > In the trunk recent additions include: > > > > * CSW support > > * ISO 19115 metadata parsing (needed for CSW support I assume) > > * Several improvements to WCS support (caching, url checking) > > * OWSCommon classes to share between services > > * A general Utils module for common functions > > > > In branches/soswfsbranch there is also: > > * Support for WFS "2.0" (IS019142) > > * Support for SOS (sensor observation service) > > > > > > My preference would be to merge soswfsbranch into the trunk sooner > > rather than > > later to prevent divergence - however this leaves the trunk with a lot > > of 'alpha' code in it (WFS2/SOS/CSW), compared to the more mature > > WMS/WFS1 > > and WCS support. > > > > What do people think about this? > > > > Should we just accept that some of the services are better supported > > than > > others and release them all anyway, say as OWSLib version 3.5 or 4.0 ? > > > > Or should we just carry on as is in the trunk without a new release > > - the > > downside being that improvements/patches such as the WCS patches > > don't get > > released onto Pypi for a while. > > > > Or should be make an effort to branch off code into stable and > > unstable > > branches and move modules across individually when 'ready' (whatever > > ready > > means)? > > > > Or should we perhaps package some things within OWSlib as > > experimental modules > > e.g. "owslib.experimental.sos" and move them across when 'ready'. > > > > There are pros and cons to each of these. Are there other options we > > should > > consider? > > > > My preference is to take the simple option and put everything in the > > trunk and > > put out a new release with the caveat that some services are better > > developed > > than others. Of course we'd need to run the tests and creating new > > ones > > where needed. > > > > My concern about having stable and unstable branches and therefore > > waiting for > > code to be 'finished' is that we don't have much development effort > > on this > > project - a few people do a bit here and there but only as time > > allows. I'm > > not sure things will ever be finished as such, just improved upon. I > > think > > the incremental approach is therefore going to suit the project > > better. > > > > If something is really unstable then yes it should probably be in a > > branch > > temporarily, but I think the default approach should be to get code > > into the > > trunk (and version released) sooner rather than later. > > > > Anyway, it's up for discussion, what do others think? > > > > Cheers, > > > > Dom > > I'm +1 with an incremental approach and getting code into the trunk > quickly. > > Another release strategy to consider is to make owslib a namespace > package, and separately distribute owslib.wms, owslib.wfs, etc. > > Before we make more releases, let's revisit the interfaces that Dom > and I came up with (interfaces.py) and make sure the SOS and CSW stuff > implement them. The interfaces themselves may need some adjustment to > accomodate. > > Sean > > -- > Sean Gillies > Software Engineer > Institute for the Study of the Ancient World > New York University > > _______________________________________________ > Community mailing list > [email protected] > http://lists.gispython.org/mailman/listinfo/community > > _______________________________________________ > Community mailing list > [email protected] > http://lists.gispython.org/mailman/listinfo/community _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
