...
- all developers on the project have consensus that a release is to be made, please send a message to the mailing list (dev@lists.amdatu.org) requesting whether there are any known issues that need to be addressed or whether there is someone who is currently working on something that should be included;
- all code compiles (inside and outside an IDE) and all tests run successfully;
- verify that all external dependencies are released, or are embedded inside (to be) released artifacts. We cannot release anything that is depending on something that is still subject to change and may break a release in the future;
- verify that everything builds against specific versions, or at least bound version ranges. Do not release anything that builds against "latest" or open version ranges as it might break when newer versions of those dependencies are released;
- the versions of the to-be-released bundles are properly bumped, for example, by releasing them with Bndtools to the local release repository of the project (which uses baselining internally to determine the proper next version);
Check the packageinfo files after doing this, they sometimes revert to version 1.0.0! - all sources have the correct license headers and copyright attributions, which can be found here;
- a short "README" file in MarkDown (ReadMe.md) is available that provides pointers on how to get started; please use this template.
- License and Notice files which are correct and up to date are included in the project. The License file can be found here, please use this template for the Notice file;
- a wiki entry exists for the project to provide a place for development discussions on the project. Please use this template to create a wiki entry when none exists prior to the release to be made.
- all the latest bundle versions are correctly released to the local release repository (cnf/releaserepo). The version to end up in the Amdatu repository should be correctly baselined and equal to the one in the local release repository.
If the release includes fixes reported by JIRA issues, make sure that all those JIRA issues have their "Fix Version(s)" field filled. By convention, this should be the "next" version, which is to be renamed once the release is promoted successfully. Tagging JIRA issues with a fix version allows you to easily create filters that can be used to summarise changes in a release.
...