Update extension to 'candidate' maturity level#37
Conversation
|
Are there 3 implementations and no planned breaking changes in the issue tracker? :) I was surprised by how extensive the documentation is now 👌 |
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.
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. |
|
Good point @m-mohr |
|
Not necessarily all issues, but if breaking changes are in the pipeline, we usually hold the extension maturity back for a bit. |
|
The above issues are now addressed. no breaking changes are planned. I think we can update the maturity level now? |
|
We should have a |
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
Type of Change
Checklist
CONTRIBUTING.mdguide;make check;Googleformat for all the methods and classes that I used.