[Gdal-dev] Radical OGR Update

Daniel Morissette dmorissette at dmsolutions.ca
Thu Feb 19 14:06:34 EST 2004


Frank Warmerdam wrote:
> 
> I hate trying to keep track of what version changes go into when there are
> branches other than the "development trunk".  I have seen branches cause
> untold hassles in projects like GRASS and to a lesser extent in MapServer.
> 

I don't think we had that many problems with branches in MapServer?
There was some confusion on the branch and tag names at some point but I
think we're doing better since version 3.6 now that we name them
consistently ("branch-x-y" and "rel-x-y-z"). Using the branches work
very well and allow us to continue to support stable releases while
working on major restructuring in the main trunk.  As you know MapServer
has undergone quite a few major changes in the last 2 years and without
CVS branches it would have been almost impossible to support the users.

All this to say: I think a stable branch should be created after the 1.2
release and before you start the restructuring.  Then *bugfix* releases
should be done as required using 1.2.x version numbers.

Also, I would like to suggest that you stop being cheap on version
numbers ;) ... instead of going with 1.1.x when new features or new
drivers are added, I think you should go 1.2, 1.3, 1.4 and use the last
digit of the version numbers only for bug fix releases (after creating a
stable branch in CVS).  That's how most projects seem to work, that also
how we do things with MapServer and that works very well.


> So, once I am ready to start restructuring I may create a 1.2 branch for
> fixes to a "stable 1.2" series, but I won't if I can avoid it.  
> Restructuring
> would happen in the trunk of course.
> 

Great!  But I don't think you can avoid it.  ;)

My 0.02$

Daniel
-- 
------------------------------------------------------------
  Daniel Morissette               dmorissette at dmsolutions.ca
  DM Solutions Group              http://www.dmsolutions.ca/
------------------------------------------------------------






More information about the Gdal-dev mailing list