Skip to content

Commit 6f0c290

Browse files
authored
docs: Add dependency and version change guidelines (#3745)
* Add dependency and version change guidelines Added guidelines for managing dependencies and version changes to ensure stability in the Awkward ecosystem. * Format contributing guidelines for clarity
1 parent c278ee6 commit 6f0c290

File tree

1 file changed

+38
-0
lines changed

1 file changed

+38
-0
lines changed

CONTRIBUTING.md

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -314,3 +314,41 @@ python -m pip install --upgrade awkward
314314
python -m pip uninstall --yes awkward awkward-cpp
315315
python -m pip install --upgrade --extra-index-url https://pypi.anaconda.org/scientific-python-nightly-wheels/simple awkward
316316
```
317+
318+
### Guidelines for Dependency and Version Changes
319+
320+
To ensure stability and reproducibility across the Awkward ecosystem:
321+
322+
1. Collaborative Review Required
323+
- Pull requests that affect core dependencies (e.g., Numba, Pandas, PyArrow, NumPy) or Python version support must be discussed with maintainers before merging.
324+
- This avoids unilateral decisions that could break critical workflows.
325+
326+
2. Compatibility Transparency
327+
- If a dependency is not yet available for a new Python release, note this clearly in the PR description and documentation.
328+
- Example: “Supports Python 3.14, but Numba-dependent features are disabled until upstream support is released.”
329+
330+
3. Testing Expectations
331+
- CI should run against all supported Python versions.
332+
- Tests that depend on unsupported features (e.g., Numba on Python 3.14) must be marked with xfail so contributors see the limitation.
333+
334+
4. Version Pinning
335+
- Pin or constrain versions of critical dependencies to prevent silent breakages from upstream changes.
336+
- Floating versions may be allowed for secondary utilities, but core scientific packages should be locked.
337+
338+
5. Communication
339+
- Use GitHub Discussions or Issues to propose changes before opening a PR that alters compatibility.
340+
- This ensures consensus and avoids surprises for downstream users.
341+
342+
343+
344+
---
345+
346+
#### Example PR Checklist
347+
348+
- Have I discussed this change with maintainers?
349+
350+
- Did I document limitations (e.g., missing Numba support)?
351+
352+
- Are CI tests updated to reflect compatibility status?
353+
354+
- Did I pin or constrain critical dependencies?

0 commit comments

Comments
 (0)