Update extension to 'candidate' maturity level

[fmigneault]

Description

Given the number of participants in the paper, and the actual publishing of the paper, we can consider the extension is a fairly stable state.

As per Extension Maturity, it is time to move it to Candidate.

Related Issue

• update crim and terradue icons + add terradue to readme #36
• deprecated in favor of MLM extension ml-model#16

Type of Change

• 📚 Examples, docs, tutorials or dependencies update;
• 🔧 Bug fix (non-breaking change which fixes an issue);
• 🥂 Improvement (non-breaking change which improves an existing feature);
• 🚀 New feature (non-breaking change which adds functionality);
• 💥 Breaking change (fix or feature that would cause existing functionality to change);
• 🔐 Security fix.

Checklist

• I've read the CONTRIBUTING.md guide;
• I've updated the code style using make check;
• I've written tests for all new methods and classes that I created;
• I've written the docstring in Google format for all the methods and classes that I used.

[m-mohr]

Are there 3 implementations and no planned breaking changes in the issue tracker? :)

I was surprised by how extensive the documentation is now 👌

[rbavery]

Are there 3 implementations and no planned breaking changes in the issue tracker? :)

There's one issue being discussed that could include a breaking change, #31, if we remove torch.compile as an artifact_type option and instead introduce a new jit_compiled field. Following the Candidate guidelines, this would require a new version. This isn't planned/decided yet, going to discuss this and some other issues with Francis when we meet up next week at SigSpatial.

Mostly stable, breaking changes require a new version and minor changes are unlikely.

given that we would increment the version if there was a breaking change and have been following this practice for awhile after the 1.0.0 version I think Candidate makes sense.

[fmigneault]

Good point @m-mohr
We might need to hold off a bit longer until all issues are resolved.

[m-mohr]

Not necessarily all issues, but if breaking changes are in the pipeline, we usually hold the extension maturity back for a bit.

[rbavery]

Makes sense, I talked with Francis and here are breaking changes we will resolve before advancing. Besides this no others are in the pipeline

revise norm types: #24
require certain statistics if certain normalization is specified: #26
revise artifact_type, add mlm:compile_method: #31