Contributing
- Adding a new pipeline
- Code editor plugins
- Code formatting
- Contributing to an existing pipeline
- DSL2 Modules
- DSL2 Subworkflows
- Developer Tutorials
- Gitpod
- Graphic design guidelines
- Guidelines
- Pipeline Release Review Guidelines
- Release checklist
- Special content elements
- Synchronisation
- Test data guidelines
- Training material guide
Pipelines must be released with stable release tags. Releases must use GitHub releases and keep a detailed changelog file.
Release version tags must be numerical only (no v prefix) and should follow semantic versioning rules: [major].[minor].[patch]
For example, starting with with a release version 1.4.3, bumping the version to:
1.4.4would be a patch release for minor things such as fixing bugs.1.5would be a minor release, for example adding some new features.2.0would correspond to the major release where results would no longer be backwards compatible.