DOC: add minimum dependency version policy in writing #10824
Conversation
doc/devel/min_dep_policy.rst
Outdated
| .. _min_deps_policy: | ||
|
|
||
| ====================================== | ||
| Minimum Version Of dependencies Policy |
There was a problem hiding this comment.
Not quite sure, what the capitalization policy really is, but everything capitalized except "dependencies" is a bit weird.
devdocs says
For everything but top-level chapters, use Upper lower for section titles
Don't know if this is a top-level chapter (and if so, what the policy for these were.
There was a problem hiding this comment.
That is indeed a typo...
doc/devel/min_dep_policy.rst
Outdated
| We will bump the minimum python and numpy versions as we can every | ||
| minor and major release, but never on a patch release. | ||
|
|
||
| Other Dependencies |
There was a problem hiding this comment.
I would split this into separate sections "Python packages" and "System/c-dependencies".
a388abc to
17680c1
Compare
doc/devel/min_dep_policy.rst
Outdated
| For system or c-dependencies (libpng, freetype, GUI frameworks, latex, | ||
| gs, ffmpeg) support as old as practical. These can be difficult to | ||
| install for end-users and we want to be usable on as many systems as | ||
| possible. We will only bump these when absolutely necessary. |
There was a problem hiding this comment.
I would prefer a slightly less restrictive policy on C-level dependencies, something like "when bumping the dependency solves a real problem (for yet-to-be defined value of "real") and the new version is available on the latest (or whatever) Ubuntu LTS and Homebrew" (for example).
There was a problem hiding this comment.
Went with " We will bump these on a case-by-case basis." which is even vaguer.
|
This does not address the dependencies that we vendor, we can in principle be more aggressive about bumping those as if we can not find a new enough version we provide it (but that would probably annoy the linux distributions). |
No description provided.