[Gdal-dev] Radical OGR Update

[Frank Warmerdam]

Daniel Morissette wrote:
> 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.

Daniel,

Well, I for one was intimidated by the MapServer branches.  I mostly just
kept my head down and worked on the trunk.  I'm not saying it is wrong for
MapServer or other packages to manage branches. I'm just nervous about
adding the conceptual overhead to GDAL.

> 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.

As far as I know, I can create a branch at any time against a particular
tag, so it wouldn't necessarily have to be done in advance.  Is that correct?

> 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.

Do you have a concept of how much major version numbers cost?  I am working
on a budget here, not a big corporate environment like DM Solutions, flush
with money.  I pay for every version number out of my own pocket!

Ok, more seriously, yes I have been rather bizarely nervous about changing
the the major or even the minor release number for GDAL.  I would agree that
a restructured library (assuming it is not very backward compatible) would
be a 2.0, and thereafter "first dot" releases would be used for significant
improvements in capabilities and "second dot releases for minor updates with
no significant improvements in capabilities.

However, as I am very adverse to backward incompatible changes in APIs,
I may well stay in the 2.x until I run out of "first dot" single digit
versions.

I remember when a bunch of my friends worked at WATCOM and they jumped to
WATCOM 8.x (from something like 4) just so their major version would be
higher than the one for Visual C++, thus making them seem more advanced.
I guess my vanity manifests in other ways than large version numbers.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent