[fdo-dev] SHP build broken in trunk

[Dan Stoica]

I totally agree with Mateusz.

That was my theory about branches as well. Once it's stabilezed it is
shipped as X.y release. Some features may be ported to other branches
but I don't see the reason to port everything.


Dan.

-----Original Message-----
From: Mateusz Loskot [mailto:mateusz at loskot.net] 
Sent: Thursday, November 09, 2006 12:48 PM
To: dev at fdo.osgeo.org
Subject: Re: [fdo-dev] SHP build broken in trunk

Dan Stoica wrote:
> BTW, I think this requirement to merge back to the trunk will be a 
> source of problems L

May I ask why FDO uses separate branch for "freezing" code and bug
fixing and then all stuff is merged back to trunk, instead of freezing
in the trunk?

>From my experience, the most popular procedure I've observed/used is:

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

IMHO, private branch for bug fixing only and back-merging to trunk is
pretty complicated. Anyway, the trunk needs to freeze (close for new
features) for this cycle.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org
For additional commands, e-mail: dev-help at fdo.osgeo.org