`docs/stability.rst` should be updated
See original GitHub issueDescription
docs/stability.rst
hasn’t been touched for quite some time now, and I don’t see any open pull requests that would update it. Given that an LTS release is upcoming the file should be reviewed.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:3
- Comments:12 (12 by maintainers)
Top Results From Across the Web
Stability and Updates | Widget API - Figma
Stability and Updates. This section is about: How new API updates are released. How the Figma team provides stability to published widgets.
Read more >Stability - Developer Platform Overview
The Benchling Python SDK obeys Semantic Versioning, meaning that breaking changes will only be made when a new major version is released. Because...
Read more >Composer problems: ... "does not match the constraint" - Drupal
I tried to install the promising Entity Pager module. ... composer.json has been updated Running composer update drupal/entity_pager Loading ...
Read more >Stability on Small Boats
These were new boats that were tender, that is “tippy”, ... Generally the owner would say the boat lists to one side, usually...
Read more >Chp. 14 - Google Docs - Stability and change from childhood ...
stability and change from childhood to adulthood temperament behavioral style and characteristic ... -First impressions, familiarity and similarity.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I personally think we should now get rid of the document and treat all sub packages as stable and have a higher bar of entry for future code to treat it on the same footing as other code. We could still add a note to specific classes or methods if they are to be considered experimental like we did for SpectralCoord?
I think it’s more important to have a well defined process for deprecations, which can still happen in any package (eg clobber in io.fits)
Also agree we can remove it - while some modules may still get major new functionality (
uncertainties
…), I don’t think that is particularly useful information, and in any case that could be displayed in the module documentation itself. What counts is whether we can commit to a more or less stable API for whatever we have, which I think is the case.