Skip to content

VERSIONING.md

Latest commit

 

History

History
121 lines (87 loc) · 3.99 KB

VERSIONING.md

File metadata and controls

121 lines (87 loc) · 3.99 KB
Raw

Versioning policy

Disk Cleaner follows Semantic Versioning 2.0.0: MAJOR.MINOR.PATCH.

Version-bump rules

Change type Bump Example
Backward-incompatible public API break MAJOR 1.0.0 → 2.0.0
Backward-compatible new feature MINOR 1.0.0 → 1.1.0
Only bugfix / refactor / documentation PATCH 1.0.0 → 1.0.1
New file format / DB schema (with migration) MINOR data layer stays compatible
DB schema change without migration MAJOR rare, should be avoided

Public API surface

The following surfaces are covered by SemVer:

  • All *.py modules under disk_cleaner/api/ (control socket)
  • The control socket JSON protocol (/tmp/disk_cleaner_$(id -u).sock)
  • CLI flags (disk-cleaner --scan, --clean, --dry-run, output formats)
  • The Cleaner rule JSON schema (~/.config/disk_cleaner/cleaners/*.json)
  • Scanner / Cleaner / VizStrategy extension points (see docs/API.md)

The following are internal and out of SemVer scope:

  • disk_cleaner/controllers/, disk_cleaner/core/, disk_cleaner/_*.py
  • The du_cache.db / snapshots.db SQLite schemas (not user-visible; may change via migration)
  • UI internal classes (disk_cleaner/ui/)
  • Theme / palette constants

0.x rules

Until v1.0.0 (currently v0.1.0), a MINOR bump may include a breaking change, but:

  • The CHANGELOG marks it explicitly as "BREAKING"
  • Migration is automated whenever possible
  • Upgrades from the previous MINOR are supported for at least one release

Pre-release tags

Tag Meaning Example
-alpha.N Internal testing 0.2.0-alpha.1
-beta.N Public early testing 0.2.0-beta.1
-rc.N Release candidate 0.2.0-rc.1

PEP 440 / Python packaging: pip orders these automatically (0.2.0a1 < 0.2.0b1 < 0.2.0rc1 < 0.2.0). If pyproject needs it, __version__ can be converted to PEP 440 form.

Release process

1. Preparation (per release)

# Pick the version number
VERSION=0.1.1

# Update pyproject.toml
sed -i "s/^version = .*/version = \"${VERSION}\"/" pyproject.toml

# CHANGELOG.md — [Unreleased] → [${VERSION}] — YYYY-MM-DD
# debian/changelog — new entry (manual instead of `dch -i`, codename unchanged):
#   codechu-disk-cleaner (${VERSION}-1ubuntu1~noble1) noble; urgency=medium

# Add an AppData release entry
# In packaging/disk-cleaner.appdata.xml, add a new <release> inside <releases>

# Lint + test
ruff check .
pytest -q

2. Commit + tag

git add pyproject.toml CHANGELOG.md packaging/debian/changelog packaging/disk-cleaner.appdata.xml
git commit -m "release: v${VERSION}"
git tag -a "v${VERSION}" -m "Disk Cleaner v${VERSION}"
git push origin main
git push origin "v${VERSION}"

3. Automated

After the tag is pushed:

  • appimage.yml GitHub Actions runs → AppImage is built and uploaded to the Release
  • GitHub Release notes are generated by the workflow (the CHANGELOG entry can be reused)

4. Manual (per channel)

  • Launchpad PPA: debuild -S -sa -k$KEY_ID && dput codechu-ppa ../*_source.changes
  • Flathub (if applicable): in the flathub/io.github.codechu.DiskCleaner repo, bump manifest.yaml to tag: v${VERSION} and open a PR (later releases automate this)
  • Snap (if applicable): set version: '${VERSION}' in snapcraft.yaml, then snapcraft pack && snapcraft upload

5. Post-release

# Add a new [Unreleased] heading to the CHANGELOG
# Do not pre-bump pyproject — the next release will bump it again

Version ↔ Ubuntu codename matrix

Each release's debian/changelog should support these codenames:

Ubuntu Codename LTS? Disk Cleaner support
24.04 noble LTS ✅ Primary
24.10 oracular — ✅
25.04 plucky — ✅
25.10 questing — ✅
26.04 resolute LTS ✅ Primary (App Center)

A single debian/changelog builds on Launchpad — via the copy-binaries feature or multiple changelog entries.