docs: Document our approach to breaking changes #35
Conversation
github-actions
bot
added
the
documentation
| @@ -42,6 +42,7 @@ documentation and then open it in your web browser using the commands below: | |||
| .. code-block:: bash | |||
|
|
|||
| # Run build | |||
| pixi run -e docs postinstall | |||
There was a problem hiding this comment.
just noticed this locally: need to postinstall first because the docs feature is not part of the default environment.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #35 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 38 38
Lines 1845 1845
=========================================
Hits 1845 1845 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| @@ -0,0 +1,10 @@ | |||
| Breaking changes | |||
There was a problem hiding this comment.
I'd like to talk about major releases here as well. We should either (1) commit to never actually making breaking changes without releasing a new major version or, at least, (2) promise a warning for X minor releases/Y months before we make the breaking change. I'd personally propose to go for (1).
There was a problem hiding this comment.
(1) sounds great. For nullability, we will do (2) though, right? So I'm not sure I can put (1) in the text xD
There was a problem hiding this comment.
I think it would be fine to do a major release in a couple months 🤔 but happy to talk about this, we definitely shouldn't document something that we're going to deviate from though 😄
Co-authored-by: Oliver Borchert <oliver.borchert@quantco.com>
Motivation
We want to agree on how to deal with breaking changes.
Changes
FutureWarningsto communicate about incoming breaking changes.