Jmm/release 1.11.0 rc

[Yurlungur]

PR Summary

Release for version 1.11.0, contains a large variety of bug fixes and, importantly, the swap to depending on PortsOfCall::Variant.

PR Checklist

• Adds a test for any bugs fixed. Adds tests for new features.
• Format your changes by using the make format command after configuring with cmake.
• Document any new features, update documentation for changes made.
• Make sure the copyright notice on any files you modified is up to date.
• After creating a pull request, note it in the CHANGELOG.md file.
• LANL employees: make sure tests pass both on the github CI and on the Darwin CI

If preparing for a new release, in addition please check the following:

• Update the version in cmake.
• Move the changes in the CHANGELOG.md file under a new header for the new release, and reset the categories.
• Ensure that any when='@main' dependencies are updated to the release version in the package.py

[jhp-lanl]

I haven't kept track of recent changes. Will this release also depend on the new spiner release? I would assume it will

[Yurlungur]

I haven't kept track of recent changes. Will this release also depend on the new spiner release? I would assume it will

Yes, just for consistency. But in practice it won't be necessary to bump them synchronously if you're managing your own spackage, as EAP does.

[jhp-lanl]

I haven't kept track of recent changes. Will this release also depend on the new spiner release? I would assume it will

Yes, just for consistency. But in practice it won't be necessary to bump them synchronously if you're managing your own spackage, as EAP does.

Ah yes, of course. The new spiner will of course depend on the new ports-of-call, but there are no new spiner features that singularity-eos depends on.

So I assume there will be no changes to the spackage regarding spiner, right?

[Yurlungur]

I haven't kept track of recent changes. Will this release also depend on the new spiner release? I would assume it will

Yes, just for consistency. But in practice it won't be necessary to bump them synchronously if you're managing your own spackage, as EAP does.

Ah yes, of course. The new spiner will of course depend on the new ports-of-call, but there are no new spiner features that singularity-eos depends on.

So I assume there will be no changes to the spackage regarding spiner, right?

yep that's right