diff --git a/Repo-docs-RELEASE-DEPENDENCIES.-.md b/Repo-docs-RELEASE-DEPENDENCIES.-.md new file mode 100644 index 0000000..a71cf77 --- /dev/null +++ b/Repo-docs-RELEASE-DEPENDENCIES.-.md @@ -0,0 +1,83 @@ + + +> Mirrored from `/mnt/DATA/git/govoplan-core/docs/RELEASE_DEPENDENCIES.md`. +> Origin: `repository`. +> Active tasks and changing state belong in Gitea issues; this wiki page is durable project context. + +--- +# 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: + +```bash +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: + +```bash +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: + +```bash +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: + +```text +govoplan-access git@git.add-ideas.de:add-ideas/govoplan-access.git v0.1.4 +govoplan-admin git@git.add-ideas.de:add-ideas/govoplan-admin.git v0.1.4 +govoplan-tenancy git@git.add-ideas.de:add-ideas/govoplan-tenancy.git v0.1.4 +govoplan-policy git@git.add-ideas.de:add-ideas/govoplan-policy.git v0.1.4 +govoplan-audit git@git.add-ideas.de:add-ideas/govoplan-audit.git v0.1.4 +govoplan-files git@git.add-ideas.de:add-ideas/govoplan-files.git v0.1.4 +govoplan-mail git@git.add-ideas.de:add-ideas/govoplan-mail.git v0.1.4 +govoplan-campaign git@git.add-ideas.de:add-ideas/govoplan-campaign.git v0.1.4 +``` + +## 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: + +```bash +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: + +```bash +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 access, admin, tenancy, policy, audit, 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, access, admin, tenancy, policy, audit, 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.