Update adding_pipelines.md for non-compliant releases

[pinin4fjords]

A suggestion on how we might mark any releases we allow without full adherence to nf-core standards (if we decide to do/ continue doing that).

See https://nfcore.slack.com/archives/C043UU89KKQ/p1689199599300659 for origin story.

[netlify[bot]]

✅ Deploy Preview for nf-core ready!

Name	Link
🔨 Latest commit	fedbf47e47f8ae96eb83395b6fd9c2323d13b891
🔍 Latest deploy log	https://app.netlify.com/sites/nf-core/deploys/64afb8ac29130b0008ef5020
😎 Deploy Preview	https://deploy-preview-1861--nf-core.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[jfy133]

We need to decide if we support -rc tags or do this in other ways, and agree we need examples.

[pinin4fjords]

Also suggested a timeline for compliance- having it before any future major or minor releases (though allowing patches during non-compliance) seems like a good way of making sure it happens.

[pinin4fjords]

Would be good with some examples for these exceptional cases.

Agreed- I just wasn't clear on what those would be, since my natural inclination is to just wave the big stick from the start.

[edmundmiller]

I like it, the only question is where a -rc in tags will break any tooling 🤔 But I guess we can cross that bridge when we get there.

I was thinking maybe these pipeline should live in dev, but then the reproducibility will struggle because people won't lock down a version tag.

[SPPearce]

What does -rc stand for?

[pinin4fjords]

What does -rc stand for?

'release candidate'

[ewels]

I don't love this to be honest. I think that nf-core pipelines should only really be released if they are nf-core compliant. The way this reads sounds to me like someone can release a random pipeline under nf-core in some situations.

I added a reply in the Slack thread. But I kind of think that this should remain undocumented. It should be exceptional to the case where it basically never happens, the same as breaking any other guidelines (it can happen sometimes but we try to avoid). By documenting a procedure we essentially set a precedent and implicitly give it an ok.

[pinin4fjords]

I think that nf-core pipelines should only really be released if they are nf-core compliant.

I couldn't agree with this more. It's just that releases do seem to be happening with content that doesn't look very nf-corey, and I felt the need to understand and document the parameters within which that happens.

In the absence of this sort of documentation, if I'm a new developer seeing newly released code that isn't written/ organised to standards people are holding me to in PRs, I'm going to be asking some pretty pointed questions about why that is.

From your comment in Slack there seems to be some distinction between 'guidelines' and 'best practice' I hadn't clocked though- so perhaps that's where the additional documentation is needed...

[jfy133]

Maybe we could have some 'internal' core/maintainers docs?

[SPPearce]

What does -rc stand for? 'release candidate'

I thought that might be the case. But I don't think that is an appropriate name to use, as this is explicitly for things that we don't think are a good candidate for release.