govoplan-core/docs/RELEASE_DEPENDENCIES.md

GovOPlaN Release Dependencies

Release installs must not depend on sibling checkout paths. Local development can keep editable installs and file: WebUI links, but release packaging should resolve modules from tagged git refs or from a package registry.

Backend

Local development:

cd /mnt/DATA/git/govoplan-core
./.venv/bin/python -m pip install -r requirements-dev.txt

Release install from a core checkout plus tagged module repositories:

cd /mnt/DATA/git/govoplan-core
./.venv/bin/python -m pip install -r requirements-release.txt

.[server] is resolved relative to the current working directory. If you create the virtualenv elsewhere, still run the install command from the core checkout:

cd /mnt/DATA/git/govoplan-core
/tmp/govoplan-release-test/bin/python -m pip install -r requirements-release.txt

requirements-release.txt pins the module repositories to the release tag. Update those refs when cutting a release:

govoplan-files    git@git.add-ideas.de:add-ideas/govoplan-files.git    v0.1.1
govoplan-mail     git@git.add-ideas.de:add-ideas/govoplan-mail.git     v0.1.1
govoplan-campaign git@git.add-ideas.de:add-ideas/govoplan-campaign.git v0.1.1

WebUI

Local development uses webui/package.json, which may point at sibling module checkouts while active development is happening.

Release WebUI installs should use webui/package.release.json. It points module dependencies at the same tagged git repositories. After the module tags referenced there exist, generate the committed release lockfile without touching the development package files:

cd /mnt/DATA/git/govoplan-core
scripts/generate-release-lock.sh
cd webui
PATH=/home/zemion/.nvm/versions/node/v22.22.3/bin:$PATH /home/zemion/.nvm/versions/node/v22.22.3/bin/npm run build

The module repositories include root-level npm package manifests so git installs can resolve @govoplan/files-webui, @govoplan/mail-webui, and @govoplan/campaign-webui from repository roots even though their source lives below webui/src.

The normal release path is automated by scripts/push-release-tag.sh: it bumps or accepts the target version, updates Python/WebUI/module manifest versions, commits/tags/pushes the module repositories first, regenerates webui/package-lock.release.json, and then commits/tags/pushes core. If the working tree has already been bumped, pass the current version explicitly:

cd /mnt/DATA/git/govoplan-core
scripts/push-release-tag.sh --version 0.1.2

Release lockfile strategy

The supported release composition currently is the full Multi Seal Mail product: core plus files, mail, and campaign. Keep one committed full-product release lockfile at webui/package-lock.release.json, generated from webui/package.release.json in a clean release workspace. Development package-lock.json may continue to point at local file: dependencies.

Frontend module permutations are regression-tested through GOVOPLAN_WEBUI_MODULE_PACKAGES and temporary build output, not through committed lockfiles for every possible combination. If a smaller composition becomes a separately shipped product, add an explicit release manifest and lockfile pair for that product, for example package.release.files-mail.json and package-lock.release.files-mail.json, generated in a clean release workspace from tagged git dependencies.

Release Checklist

• Keep Python package versions, WebUI package versions, and git tags aligned.
• Tag core, files, mail, and campaign repositories together.
• Update requirements-release.txt and webui/package.release.json when the release tag changes.
• Generate the committed full-product release lockfile from package.release.json with scripts/generate-release-lock.sh.
• Add separate release manifest/lockfile pairs only for module compositions that are shipped as their own products.
• Do not commit local sibling paths into release manifests.