[Community] OWSLib release strategy?

[Dominic Lowe]

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