- A policy is needed to allow easy collaborative software development.
- The project will at any point in time be working towards a documented set of features for the next major release, see the DNA project specification for the current definition of these features.
- The path to major releases may be punctuated by point releases as features are completed and tested.
- Existing releases may include bugs which require fixing. This will give rise to minor releases.
- The CVS trunk is designated as the single location where the latest stable release can be checked out. Great care must be taken to avoid corrupting this. A limited set of people can commit to the trunk.
- A permanent branch (developers_branch) is used by developers to keep source between releases, instead of the trunk.
- If necessary individual branches can be created. These allow single developers to keep source separate when making major changes that may be unstable for some time.
- The project's CVS manager is responsible for deciding when a release is ready and merging in to the trunk.
- Think twice before committing.
Commits will be taken by all developers. Broken code will be broken for everybody. CVS does allow fairly easy recovery but take care so as to avoid the need.
- Never commit code that doesn't compile.
Compile and correct code before committing. Ensure new files that compilation requires are also committed. Be especially careful if you change the build system.
- Don't commit code you don't understand.
Avoid things like "I'm not if this is right but it works for me". If solutions cannot be found discuss with other developers.
- Test changes before committing.
Start DNA and make sure the code behaves as desired. Run automated tests.
- Double check what you commit.
Use CVS commands to check changes before committing. Takes messages about conflicts, patches etc seriously. The "cvs diff" command will tell you what you will be committing. Check it's what you really intend.
- Don't commit changes to public APIs without prior review by other developers.
These changes will affect other developers. Reviewing these changes should avoid problems and conflict.
- Don't mix formatting changes with code changes.
Mixing such changes make it very difficult to see real changes. Commit format changes separately and ensure they are logged as such.
- Always add descriptive log messages.
Log messages should ideally be understandable to someone who only sees the log. Try to put log messages only in those files really affected by the changes described. Put in all important information which cannot be seen from the diff.
- If you commit bug fixes consider committing to other branches also.
Fixes to bugs in the developers branch should be applied to the trunk is applicable.
- If making changes that affect a lot of different code announce them before hand.
Even if these changes look trivial they may break other code. Announcing these before hand gives the opportunity for developers to raise concerns. Changes internal to a single DNA system part need not be announced in advance (see DNA responsibility page). However, changes that span different sub parts like changes to the XML definitions should be anounced beforehand.
- Avoid to use CVS keywords like Id or Log in source files.
These changes cause unnecessary conflicts when merging branches and don't contain any information not in the repository anyway. The Id keyword can be useful when used in the header of a file, however it's up to the responsible of the DNA part of the code to decide if the Id keyword is allowed or not.
- Make "atomic" commits.
CVS can commit more than one file at a time. Commit all related changes in multiple files at one time, even if they span multiple directories. For example, if an XML definition has been changed, commit the XSD file changes together with the changes to the Java or Python code affected by the definition change.