Skip to main content

Release and repo hygiene

Checklist for first and ongoing releases of the edox-ops Python package, dependency updates, and GitLab project settings. Package build and publish steps live in package-release.md. The path from 0.1.0 to 1.0.0 (VPS proof, docs migration, stability) is in roadmap-1.0.md.

Before the first tag (v0.1.0)​

StepAction
LicenseLICENSE (Apache-2.0) present; pyproject.toml license = "Apache-2.0"
VersionConfirm src/edox_ops/__init__.py __version__ is 0.1.0 (or intended release)
ChangelogUpdate CHANGELOG.md — move items from [Unreleased] to [X.Y.Z] with date
CI greendevelop pipeline: ruff, audit:python, audit:website, unit, integration ×3
CI variablesSettings → CI/CD → Variables — TWINE_PASSWORD_TESTPYPI, TWINE_PASSWORD_PYPI (masked, protected)
DependabotSettings → Repository → Dependabot — enable; config in .gitlab/dependabot.yml
Branch protectionProtect master (maintainers only, pipeline required); protect develop as needed
TagOn master after ff-merge: git tag -a v0.1.0 -m "Release 0.1.0" → git push gitlab v0.1.0

Tag pipeline is fully automated except publish:pypi (manual). See Automated release pipeline.

Dependency updates​

MechanismScope
Dependabotpyproject.toml (pip) and website/package-lock.json (npm); MRs to develop
audit:pythonCI pip-audit on runtime deps (pip install -e .)
audit:websiteCI npm audit --audit-level=critical in website/ (high/moderate tracked via Dependabot)

Review Dependabot MRs like any other change: local pytest, integration when touching host logic, make docs when Docusaurus deps change.

Ongoing release rhythm​

  1. Land features on develop; ff-merge to master when CI is green.
  2. Bump __version__, update CHANGELOG.md, commit on develop → ff-merge master.
  3. Tag vX.Y.Z on master and push the tag.
  4. CI runs build, wheel smoke, GitLab + TestPyPI publish, and TestPyPI install smoke.
  5. Click publish:pypi when package:smoke-testpypi is green.
  6. CI runs package:smoke-pypi after public upload.

Duplicate uploads are rejected — bump the version for every new publish.

Optional: signed tags and provenance​

Not required for v0.1.0. When you want stronger integrity:

git tag -s v0.1.0 -m "Release 0.1.0"

Publish your GPG public key where collaborators can verify tags. PyPI trusted publishing (OIDC from GitLab CI) is an alternative to long-lived API tokens — configure in PyPI project settings when you outgrow manual TWINE_PASSWORD_PYPI.

GitLab release notes​

After a successful tag pipeline, optionally create a Deploy → Releases entry on GitLab linking to CHANGELOG.md and the dist/ artifacts from package:build.