Add a page about procedure to follow to patch old releases

[maxulysse]

let's say you need to patch pipeline 1.0 because that's the one in prod, so you want to patch it. I'd create a 1.0 branch based on the 1.0 release, make a PR which fix the bug, if said bug still exists in dev, make a PR to dev to fix it too. If necessary pin nf-core tools to ensure linting works. Merge PRs and release from the 1.0 branch with a 1.0.fix.0 tag. If another patch need to happen on this patched release, then continue working on said 1.0 branch, and do a 1.0.fix.1 tag

I think that we should only accept bugfixes for patch releases if the bugfix also goes into dev. I think that it needs to be applied twice, no way around that. (except if the bugfix is already in dev or no longer relevant)

[ewels]

I would suggest we follow semver, not sure we need fix stuff? eg. this would be fine in chronological order:

• 1.0.0
• 1.1.0
• 1.2.0
• 1.0.1
• 1.3.0
• 1.0.2
• 1.4.0
• 1.4.1 ..etc

⚠️ Need to make sure that the website understands semver ordering before we do this for real

[mashehu]

website should already understand that 🙂