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 our socials (Bluesky and Mastodon).
• 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
  • Check that the full-size tests have successfully completed within the dev branch

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 (must be 1.0.0 NOT v1.0.1rc)
  • 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 on #release-review-trading
  • If a first release, one review must come from one core or maintainers team member - feel free to ping the two teams on slack under your post on #release-review-trading.
  • For any other release, one review can come from a member of the same development team, but we strongly recommend the second to be an another external/neutral person from the community
  • While you’re waiting for reviews on your PR, review another community member’s release PR (see pinned message in the channel above)
• Once your PR approved by two reviewers, merge your PR into master/main
  • (First release only) And finally delete any label of types: “under development”, “under construction” or variants of these on the repository
• (First release only) 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.
• Our social media accounts (Bluesky and Mastodon) will send out an automated post 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
• If your pipeline is using pipeline-level nf-test tests, update snapshots: nf-test test tests/ --profile=+<docker/singularity/conda etc.>
• 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.g. nf-core/atacseq.
• (First release only) Ask a core member to change default branch from dev to master.
• Check that AWS megatest run succesfully and that the results are made available on the website e.g.nf-core/atacseq.
• (publication only) If a publication of the pipeline is being prepared, recommended nf-core guidelines are followed.
• Post on the #bytesize_suggestion slack channel of your release, to begin arranging a 15m introductory bytesize talk about your shiny new pipeline!