[Mapbender-dev] Version control guidelines

[Ulrich Rothstein]

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
> Mapbender_dev at lists.osgeo.org
> 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:uli.rothstein at wheregroup.com
http://www.wheregroup.com
Amtsgericht Bonn, HRA 6788
-------------------------------
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
---------------------------------------