On Thu, March 13, 2008 6:11 pm, Christoph Baudson wrote: > 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 > > Hi devs,
at the last irc-meeting we had a discussion about the topic how to handle new featurs to release in new mapbender versions. Christoph send this mail about branch- and tag-based models, but we've not found a decission. So please admit me some thoughts about this topic - for a futher discussion... There seems to be no conflict for the initiation of branches for each programmer, but this way could not solve all the problems to release stable modules. If modules are integrated in new releases it may be that they are not complete. Complete means for example: - a security check - internationalisation - review of the code - and all the stuff I*ve forgotten this moment... So it maybe usefull to 'tag' them by some means or other. Sure, the tags. "stable", "release" and "development" could not indicate all states of a module, but I propose to figure out some more categories to mark the state of a module. So it may be much easier for develpers to complete modules and to evaluate the status of them. So I arrived at the conclusion that we need both, the branch and the tag-based model, to handle the modules proper. Any hints? best regards Uli -- --------------------------------------- Ulrich Rothstein WhereGroup GmbH & Co. KG Siemensstraße 8 53121 Bonn Germany Fon: +49 (0)228 / 90 90 38 - 17 Fax: +49 (0)228 / 90 90 38 - 11 mailto:[EMAIL PROTECTED] http://www.wheregroup.com Amtsgericht Bonn, HRA 6788 ------------------------------- Komplementärin: WhereGroup Verwaltungs GmbH vertreten durch: Arnulf Christl, Olaf Knopp, Peter Stamm --------------------------------------- _______________________________________________ Mapbender_dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapbender_dev
