Pratik Bhadane
307beeca02
Prepare the first public 1.0.0 release and finish the remaining CI hardening work. Highlights: - align Python, Rust, WASM, Conda, API, MCP, and docs version metadata to 1.0.0 - promote package metadata to Production/Stable and update stability/versioning docs for the stable series - move the accumulated Unreleased notes into a dated 1.0.0 changelog section and keep a fresh top-level Unreleased block - strengthen the changelog checker so it validates a single top-level Unreleased section - fix the CI/package support mismatch by declaring Python >=3.10 consistently and gating pandas-ta extras to Python 3.12+ - restore Sphinx autodoc compatibility for documented ferro_ta.<module> imports by registering module aliases - make the TA-Lib benchmark guardrail less flaky by checking median and tail-percentile speedups instead of failing on a single mild outlier - switch PyPI publishing to OIDC-only trusted publishing and wire the changelog check into the required CI gate - apply the Ruff-driven cleanup across the Python and test tree and refresh uv/cargo lockfiles Validated locally: - python3 scripts/check_changelog.py - uv run --with ruff ruff check python tests - uv run --with ruff ruff format --check python tests - uv lock --check - sphinx-build -b html docs docs/_build -W --keep-going - build/install the ferro_ta 1.0.0 wheel successfully
105 lines
4.1 KiB
Markdown
105 lines
4.1 KiB
Markdown
# API Stability Policy
|
|
|
|
This document describes which parts of **ferro-ta** are considered stable, which
|
|
are experimental, and what the deprecation process is.
|
|
|
|
---
|
|
|
|
## Stability Tiers
|
|
|
|
### Stable
|
|
|
|
The following are considered **stable** and will not change in incompatible ways
|
|
without a major version bump (i.e., following [Semantic Versioning 2.0.0]):
|
|
|
|
- All indicator functions exported from `ferro_ta.*` by name (e.g. `ferro_ta.SMA`,
|
|
`ferro_ta.RSI`, `ferro_ta.BBANDS`).
|
|
- Sub-module imports: `from ferro_ta.overlap import SMA` etc.
|
|
- Function signatures: positional array arguments and `timeperiod` / other keyword
|
|
arguments documented in the docstrings.
|
|
- Return types: single `np.ndarray` or tuple of `np.ndarray` as documented.
|
|
- Exception classes: `FerroTAError`, `FerroTAValueError`, `FerroTAInputError`.
|
|
- Utility helpers: `ferro_ta.utils.get_ohlcv`, `ferro_ta._utils.get_ohlcv`.
|
|
- `pandas_wrap` / `polars_wrap` behaviour: `pd.Series` in → `pd.Series` out;
|
|
`pl.Series` in → `pl.Series` out.
|
|
- Registry API: `ferro_ta.registry.register`, `run`, `get`, `list_indicators`.
|
|
- Pipeline API: `ferro_ta.pipeline.Pipeline`, `make_pipeline`.
|
|
- Config API: `ferro_ta.config.set_default`, `ferro_ta.config.Config`.
|
|
|
|
### Experimental
|
|
|
|
The following are **experimental** and may change in minor releases:
|
|
|
|
- **`ferro_ta.raw`** — direct access to the compiled Rust extension; function
|
|
signatures follow the Rust layer and may change when the Rust layer changes.
|
|
- **`ferro_ta.batch`** internals — the Python↔Rust dispatch logic may change as
|
|
the Rust batch API evolves.
|
|
- **`ferro_ta.streaming`** — the streaming class API (especially the `reset()`
|
|
method and internal buffer access) may evolve; the `update()` method signature
|
|
is stable.
|
|
- **`ferro_ta.extended`** — extended indicators (VWAP, SUPERTREND, etc.) are
|
|
considered stable in return shape and semantics, but implementation details
|
|
(e.g. whether computation is in Python or Rust) may change.
|
|
- **`ferro_ta.backtest`** — the backtest helpers are convenience utilities and
|
|
may be refactored.
|
|
- **`ferro_ta.gpu`** — the CuPy GPU backend is an experimental proof-of-concept.
|
|
|
|
### Internal / Private
|
|
|
|
Names prefixed with `_` (e.g. `_ferro_ta`, `_utils`, `_to_f64`) are internal
|
|
and may change at any time without notice. Do not rely on them in user code.
|
|
|
|
---
|
|
|
|
## Versioning
|
|
|
|
ferro-ta follows [Semantic Versioning 2.0.0]:
|
|
|
|
| Change type | Version bump |
|
|
|----------------------------------------|--------------|
|
|
| Breaking API change (removed indicator, renamed parameter, changed return type) | **MAJOR** |
|
|
| New indicators, new sub-modules, new features (backward-compatible) | **MINOR** |
|
|
| Bug fixes, performance improvements, docs, dependency bumps | **PATCH** |
|
|
|
|
The current version (`1.x`) is stable. Breaking changes to stable APIs are
|
|
reserved for future **major** releases.
|
|
|
|
---
|
|
|
|
## Deprecation Policy
|
|
|
|
Before removing or renaming any **stable** API:
|
|
|
|
1. The deprecated name/function is kept until the next **major release** after
|
|
the deprecation notice.
|
|
2. A `DeprecationWarning` is raised when the deprecated API is used.
|
|
3. The deprecation and removal are documented in `CHANGELOG.md` under
|
|
`### Deprecated` and `### Removed`.
|
|
|
|
Example timeline:
|
|
|
|
- `1.1.0` — `OLD_NAME` deprecated, `DeprecationWarning` added; `NEW_NAME` available.
|
|
- `2.0.0` — `OLD_NAME` removed.
|
|
|
|
---
|
|
|
|
## What is NOT covered
|
|
|
|
- The Rust ABI of the compiled extension (`_ferro_ta.so` / `_ferro_ta.pyd`).
|
|
Only the Python-level API is covered by this policy.
|
|
- Numerical precision beyond what is documented (exact TA-Lib matches for listed
|
|
indicators, "correlated" for Wilder-seeded indicators).
|
|
- Performance characteristics — we may change the implementation to be faster
|
|
(e.g. moving a Python loop to Rust) without a version bump.
|
|
|
|
---
|
|
|
|
## Requesting Stability Guarantees
|
|
|
|
If you depend on an experimental API and would like it promoted to stable, please
|
|
open an issue on GitHub explaining your use case. We will consider promoting
|
|
experimental APIs to stable when they have been in use long enough to be confident
|
|
in their design.
|
|
|
|
[Semantic Versioning 2.0.0]: https://semver.org/
|