[Mapbender-dev] Version control guidelines

[Christoph Baudson]

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.