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 [email protected] http://lists.osgeo.org/mailman/listinfo/mapbender_dev
