feature: A feature is a new introduced distinguishing characteristic of a software item. It will be called feature as long as it is not part of the code base.
trunk: trunk is the main development branch for the project(s). It underlies several rules, stated in section 1.
branch: A branch is a development part that is used for the creation of modified code (e.g. features). Rules for branches are section 2.
tag: A tag is a final branch where a release version is stored. Everything related to tags is stored in section 3.
a. The main development branch must always contain the code for the next release.
b. New features must not be directly committed to the main development branch. Exceptions are established by rule 1.1.c. Acceptable changes are: Bug Fixes, Security Fixes and language, documentation and distribution files updates. Changes regarding to enhancements may be committed to trunk if the enhancement is scheduled for the next release.
c. When a new feature is ready to be integrated into the main development branch, the developer must obtain approval from the Project Manager to reintegrate the branch into the trunk.
d. The main development branch may not be frozen at all time. Except during the release process set at 10 days. During the freeze, only last minute fixes are allowed with prior approval of the Release Manager.
Annotation: The trunk should never be frozen. For release a new branch should be created. This branch will be move to tags after reintegration to trunk — RatS 2010/02/24 23:52
a. The CHANGELOG file must be updated on every commit. Changelog entries should look like this:
YYYY-MM-DD FIRSTNAME SURNAME * [PART] Fixed #NUMBER: TEXT
Where PART is one of the following:
Multiple entries should be ordered alphabetically. A line must not contain more than 80 chars.
b. The date of commit must be the date in UTC.
c. Every commit must belong to a single change: Correction of a bug, addition of a new feature (branch reintegration) or any other task. This facilitates the work of the quality assurance team. Change reverts can be performed more easy if necessary.
Commits can be done with the following command:
$ svn WORKING_COPY $ svn up $ svn ci -m " * [PART] Fixed #NUMBER: TEXT" $ svn up
If someone else is the author of a patch the name of the author should be added in round brackets.
a. Developers should never perform partial merge of a branch into the trunk. For the full reintegration of a branch into the trunk, the [u]Project Manager[/u] has to be consulted. On Project Manager's okay, the reintegration can be done with the following command:
$ svn WORKING_COPY $ svn up $ svn merge --reintegrate http://isp-control.net/ispcp_svn/trunk $ svn up
b. Partial merges are allowed to collapse different branches with same scoop.
a. The branches should be used to develop of new features or hold a version ready to release.
b. Every branch has a responsible developer, the so called _branch developer_. For a release version the _Release Manager_ is the branch developer.
c. The feature branch developer should keep their branch up to date. He/she has to perform regular synchronization with the trunk and need to resolve conflicts properly.
a. A release branch must be named after the upcoming release and will be created by the _Release Manager_ with the following command, where x.y.z is the number of the release.:
$ svn copy http://isp-control.net/ispcp_svn/trunk http://isp-control.net/ispcp_svn/branches/omega-x.y.z
b. Each feature should have its own branch and must be initialized from the trunk. Use the following command for this:
$ svn copy http://isp-control.net/ispcp_svn/trunk http://isp-control.net/ispcp_svn/branches/FEATURE-NAME-dev
The same rules as for 1.2 are valid.
As specified in paragraph 2.1.c developers must perform regular synchronization of their branch with the trunk. The Synchronization should be made with the following commands:
$ svn WORKING_COPY $ svn merge http://isp-control.net/ispcp_svn/trunk $ svn ci -m "Synchonization with main development branch" $ svn up
Partial merges from one branch into the trunk are not permitted. Exceptions can be granted by the Project Manager.
a. After the development of a feature is completed, the branch developers need to ask the Project Manager for approval to re-integrate the branch into the trunk with the following commands:
$ svn WORKING_COPY $ svn merge http://isp-control.net/ispcp_svn/trunk $ svn ci -m "Synchonization with main development branch" $ svn up $ svn merge --reintegrate http://isp-control.net/ispcp_svn/trunk
b. After successful re-integration, the branch developer has to delete the branch. This can done by using the following command:
$ svn rm http://isp-control.net/ispcp_svn/branches/YOUR_BRANCHE
a. Tags are the storage of releases. Once set, tags are immutable.
b. Tags should be only created by the _Release Manager_
c. Every tag has to follow he name convention omega-x.y.z, where x.y.z is the number of the release.
The tagging has to be done on the day of a new version with the following command:
$ svn move http://isp-control.net/ispcp_svn/branches/omega-x.y.z http://isp-control.net/ispcp_svn/tags/omega-x.y.z
a. Every developer can nominate another developer (without SVN write access) for SVN write access.
b. The majority of developers with SVN write access has to vote for the nominee.
c. The Project Manager has to prove the election and will inform and the SVN administrator to grant access to the SVN.
a. A developer who leaves the project looses SVN write access. For Developers not active over a period of a year will loose SVN write access.
b. Every developer can nominate another developer who's SVN write access should be revoked. For this the nominating developer has to inform the Project Manager who's access should be revoked for what reason. The Project Manager has to prove the reason and can either accept or reject the request. Valid reasons are listed in 4.2.c.
c. Valid reasons to revoke SVN write access are: Destruction of source code, intrusion of malware or intentional creation of vulnerabilities.
d. The SVN administrator has to remove the SVN write access in the cases of a. and accepted b.