[Mapbender-dev] Version control guidelines

[Melchior Moos]

I would vote for the branch based model. Today I played a little with a 
branch that I created for me. As far as I can say from this experience 
this would be a proper solution because merging between the 
branches/trunk is an easy process.

Christoph Baudson schrieb:
> In January, we established a release branch for 2.5, in order to avoid new
> features being forced into the released. Unfortunately, people still seem
> to use 2.5 to check in new features, instead of trunk. We need to discuss
> the way we organize data in Subversion.
>
> A branch-based model could look like this: There is the trunk, containing
> the currently developed version. In our case, this would be Mapbender 2.5.
> Older versions could exist in separate branches, like our 2.4.5 branch at
> the moment. New features would have to be developed in sandboxes, which
> could be branches as well. We could have a sandbox for each developer.
> Only if a new feature is well-tested and documented, it should be merged
> into the trunk. We would have to strengthen the role of the release owner:
> Each commit to the trunk should be reviewed, and be rejected by the
> release owner if it violated the commit guideline.
>
> Another model would be tag based: There are various tags, for example
> "stable", "release", "development". All data would be in the trunk, and on
> each commit would have to be tagged accordingly, meaning the file will be
> copied to the appropriate tag folder. I'm not sure about the actual
> proceedings here, but I have the gut feeling that developing concurrent
> versions would be next to impossible.
>
> We should agree on a policy ASAP and write it down in the wiki. Violations
> against these guidelines should be made public to assure quality and
> continouus education. We need more quality control in Mapbender and this
> might be regarded as a first step. Please suggest your favored model or
> comment on the two mentioned above. I'm all ears.
>
> _______________________________________________
> Mapbender_dev mailing list
> Mapbender_dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapbender_dev
>
>