[fdo-dev] SHP build broken in trunk

[Frank Warmerdam]

> -----Original Message-----
> From: Mateusz Loskot [mailto:mateusz at loskot.net] 
...
> 1. Long development process in the trunk
> 2. It's time to freeze
> 2.1 An announce goes to all developers with request "Don't push
> new features, only testing"
> 2.2 Bug fixes goes to trunk
> 2.3 It's stable, so let's release it
> 2.4 tag is created (not branch) with release snapshot:
> tags/release-X.Y.Z
> 3. After release has been tagged, trunk is back for next development
> cycle and accepts new features, etc.
> 
> Branches are used for longer forks for big features.
> For instance, one wants to test new RDBI drivers design,
> so he creates a private branch and applies new stuff.
> After it's finished, tested and decided to be used in the main
> development line, branch can be merged back to the trunk.
> Usually, the next step is to create new release with this new big
> feature and tag it (create named snapshot).

Folks,

In my experience a "stable branch" has been used for issuing point releases
with bug fixes.   So for instance:

1) Approaching release, so call goes out to hold off on new features, and
    focus on bug fixing/stabilization.
2) At release time, a stable branch is broken off (say a 3.2 branch).
3) Development recommences in the trunk at this point.
4) 3.2.1, 3.2.2 etc releases can be made off the 3.2 branch from time to
    time till 3.3 comes out.  The 3.2.x releases would just have bug fixes,
    that are backported from trunk.

It was pointed out in the first FDO meeting that holding off on new
development while release stabilization happens is not always practical,
in which case we could split off the "stable 3.2" branch a modest while
before 3.2 is actually released, but the downside is that fixes need to
go into the 3.2 branch and trunk at that point.

Mateusz and others also point out that branches can be used for radical
experiments and stuff.  I'm not against that, though I am personally
nervous about how this works out when it is time to merge back the changes.
The geotools guys have used branches for radical new features and found
that merge time turns into months and months of hell (at least this is
how I perceive things watching the mailing list).  So I'm not a bit fan
of routine use of branches for developing radical new features.

I think "trunk" always being the current development version is easy
to understand with branches existing for "stable branches" and
private/radical experiments.

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    | President OSGeo, http://osgeo.org