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
