Changelog ========= GitHub Releases is the canonical release-history surface for ETLPlus. It also serves as the earlier developer-preview and release-announcement surface for tagged releases, whereas the Python Package Index (PyPI) is the later public package-install channel. This page exists to point readers and maintainers to the tagged release history and to summarize how release notes are managed. Current Release --------------- The documentation published here tracks ETLPlus |release|. Recent stable-line additions reflected in the current docs include: - Portable schedule config inspection via ``etlplus schedule`` - One-shot local due-run dispatch via ``etlplus schedule --run-pending`` - Additive scheduler metadata carried through the existing ``run`` event and local-history contracts - Read-only local run-history dashboard exposed through ``etlplus ui`` - ``pipx install etlplus`` and ``uv tool install etlplus`` documented as supported isolated CLI installation paths, with release-path smoke coverage for supported installers Release History --------------- - `GitHub Releases `_ - `Git tags `_ Release Notes Policy -------------------- - GitHub Releases is the canonical changelog for tagged ETLPlus releases. - `.github/release.yml` defines the categories used for GitHub's auto-generated release notes. - `.github/RELEASE-NOTES-TEMPLATE.md` defines the maintainer checklist and structure for final release text. - The docs site does not maintain a separate running per-release changelog at this time. Documentation Publishing ------------------------ The published docs site includes: - Getting-started pages for installation, quickstart usage, and compatibility expectations - Guide pages for examples, pipeline authoring, file-handler coverage, and contributor workflows - An autogenerated API reference sourced from ``etlplus`` docstrings - CI validation for the HTML, EPUB, and linkcheck builders advertised to Read the Docs Hosted docs publication and version switching are managed by Read the Docs, not by ``.github/workflows/cd.yml``. After pushing a release tag, maintainers should confirm that the new tagged docs version is active on Read the Docs, that ``stable`` points at the intended newest stable tag, and that ``latest`` has rebuilt from the default branch.