Release 6.0.0-rc.6

[yashpatel6]

• I have read the code review guidelines and the code review best practice on GitHub check-list.

• The name of the branch is meaningful and well formatted following the standards, using [AD_username (or 5 letters of AD if AD is too long)-[brief_description_of_branch].

• I have set up or verified the branch protection rule following the github standards before opening this pull request.

• I have added my name to the contributors listings in the
  metadata.yaml and the manifest block in the nextflow.config as part of this pull request, am listed
  already, or do not wish to be listed. (This acknowledgement is optional.)

• I have added the changes included in this pull request to the CHANGELOG.md under the next release version or unreleased, and updated the date.

• I have updated the version number in the metadata.yaml and manifest block of the nextflow.config file following semver, or the version number has already been updated. (Leave it unchecked if you are unsure about new version number and discuss it with the infrastructure team in this PR.)

• I have tested the pipeline on at least one A-mini sample.

Updating call-SRC with bugfix for cases where DPClust workflow would get stuck. Bumping release candidate version to make this available along with other added enhancements

Testing Results

Pipeline-call-SRC was tested for the update: /hot/software/pipeline/pipeline-call-SRC/Nextflow/development/unreleased/yashpatel-use-updated-src-util/ILHNLNEV000001-N002-A01-F.log

[nwiltsie]

The actual code changes seem completely benign to me.

My one concern (that shouldn't block this merge) is process-based: neither the old nor the new pipeline-call-SRC commits are from the main branch, and both claim to be version 2.0.0-rc.1. Is there any way after-the-fact to determine exactly which version of a child pipeline was run?

If it's not already a rule, I think we should adopt the rule that full metapipeline releases (not candidates like this PR) must refer to official tagged releases of the child pipelines.

[yashpatel6]

The actual code changes seem completely benign to me.

My one concern (that shouldn't block this merge) is process-based: neither the old nor the new pipeline-call-SRC commits are from the main branch, and both claim to be version 2.0.0-rc.1. Is there any way after-the-fact to determine exactly which version of a child pipeline was run?

I don't believe post-run there's a way to determine version solely based on the outputs; looking at the source code with the CHANGELOG should be able to indicate it though

If it's not already a rule, I think we should adopt the rule that full metapipeline releases (not candidates like this PR) must refer to official tagged releases of the child pipelines.

This is generally a rule we've been following with metapipeline releases; I've kept unofficial/non-main versions for call-SRC in the release candidates here for testing purposes as the call-SRC pipeline gets updates but version 6.0.0 of metapipeline will have an official tagged release for call-SRC

[nwiltsie]

This is generally a rule we've been following with metapipeline releases; I've kept unofficial/non-main versions for call-SRC in the release candidates here for testing purposes as the call-SRC pipeline gets updates but version 6.0.0 of metapipeline will have an official tagged release for call-SRC

Perfect, that makes complete sense. It would be such a drag to continually make RC tags for submodules just so they can be tested in this RC.