Release checklist

Edit

Before you release

• Check the pipeline follows nf-core guidelines.
• All continuous-integration tests on the dev branch should be passing
  • Check the output of nf-core pipelines lint for warnings and address all that you can
  • Update any software dependencies that are out of date. The linting will warn about available updates via automated API calls to (bio-)conda
• Check that there are no outstanding issues that need to be addressed, especially bug reports.
• Finalize the description of the pipeline in the GitHub repository and ensure that you remove any “under development” labels in the description. This wording will be used when a new pipeline gets announced on Twitter.
• If there is a release milestone, have a look and see if all issues are closed, or can be resolved
  • It’s fine to decide that some things should be postponed until the next release - just move them on to the next milestone

Steps to release

• On your fork, bump the version number of the dev branch to a release version
  • For example, 1.0.0dev becomes 1.0.0
  • Use the nf-core pipelines bump-version command to make the changes, eg: navigate to the pipeline directory and run nf-core pipelines bump-version 1.0.0
  • Please make sure to use strictly numeric release numbers
  • Use Semantic Versioning - see the nf-core semantic versioning guidelines to decide if you need a patch, minor, or major release.
  • Make sure to update the version in any pipeline diagrams and other figures
• Run nf-core pipelines lint --release and check that there are no test failures for release.
• Check that CHANGELOG.md includes everything that has been added/fixed in this release, update the version number above the changes, and optionally add a human-readable release name (e.g. using a code name generator)
  • We recommend you also add the GitHub handle of the main contributors of each CHANGELOG entry (author, and significant reviewers etc.). This will mean each release on GitHub will display each contributors icons for extra visibility and recognition.
• Open a Pull Request (PR) with these changes from your fork to the dev branch on the nf-core repository.
• Once merged, open another PR from the nf-core dev branch to the nf-core master
  • Make sure that all of the CI tests are passing - this is a special case PR and the tests are different
  • Request PR reviews from at least two people
  • Once approved by two reviewers, merge your PR into master
  • And finally delete any label of types: “under development”, “under construction” or variants of these
• If this is a first release, ask a core team member to activate the Zenodo functionality for this repository, which will be used to generate a DOI.
• Go to GitHub and create a new release for your pipeline :::note Use exactly the same version as in the code (e.g. 1.0.0) - do not prefix with v (e.g. not v1.0.0). :::
  • Optional: Also include your nice code name in your pipeline release title (see above with CHANGELOG.md) For example releases in nf-core/rnaseq follow the pattern: - Prefix = Metal - Dictionary = Animals - Suffix = Don’t use a suffix
• Celebrate! But not too much - you still have a few things left to do…

Automated events

A number of events are automatically triggered after the pipeline is released:

• The nf-core website will be updated automatically with the release information.
• The @nf_core twitter account will send out an automated tweet about the pipeline release within minutes.
• A Zenodo DOI is automatically generated that provides a persistent means with which to cite the pipeline.

After release

The last step is to bump up the pipeline version number in the development branch:

• Make sure the dev branch on your fork is up to date
• On a new branch, bump to a new dev version
  • For example, 1.0.0 becomes 1.1.0dev
  • Use the nf-core pipelines bump-version command to make the changes, eg: navigate to the pipeline directory and run nf-core pipelines bump-version 1.1.0dev
• Update the CHANGELOG.md to include a new section for this new version
• Open a Pull Request (PR) with these changes from your fork to the dev branch on the nf-core repository.
• (first release only) After the first release of the pipeline you will need to add the DOI manually into the main README.md for the pipeline:
  • Search for your pipeline on Zenodo and find the DOI that allows you to “Cite all versions” of the pipeline.
  • Ask a core member to copy the DOI information you added to dev via the PR above to the master branch. The core member will uncomment the Zenodo-related TODO statement in the Citation section of the main README.md and add the DOI, as well as as updating the badge for the Zenodo DOI at the top of the main README.md e.- nf-core/atacseq.
• (first release only) Ask a core member to change default branch from dev to master.
• (publication only) If a publication of the pipeline is being prepared, recommended nf-core guidelines are followed.