Version Control Messages
All commits must have a message, formatted as such:
- Before release 0.1, messages without references are allowed. We will assume they are general setup changes.
- After release 0.1 all commits should begin with one of
- refs #n: where n is an issue number representing the issue addressed by the commit. This should be followed by a message if pertinent.
- Cleanup: for all cleanup code, changes to comments, updates to match the style guide. etc.
- Release: non-code changes necessary to create a release (change to about box, increment of release numbers in constants, etc.) Please append the number of the release created.
- JavaDoc: for updates to documentation of various methods and classes.
- Compliant with Checkstyle (qualyzer_checks.xml)
- Please add your name in the file header, not the class header.
- Version is the release the bug is in. Tasks should not have a version attached to it, only a milestone.
- Milestone is our goal for integrating the patch.
- As soon as you start working on an issue, please change it from New to Open
- Do not close issues until we discuss them in the scrum meeting. Afterwards the assignee is in charge of closing them.
Things to do before putting out a new release:
- Update the splash screen with the release number.
- Update the release number in the plug-in manifest.
- Update the release number in the About box.
- After code freeze, create a branch of the release (e.g., br-0.1). It is ok to create a new remote head when creating a new branch.
- Create the release notes.
- Copy the release notes on the static web site.
- Update the download shortcuts on the static web site.
- Create the zipped archives.
- Upload the archives to SourceForge
- Send an email to the mailing list with the release notes and the url for download.
- Increment the default version and milestone numbers in the issue database.