Skip to content

Add version bump and propagate script #32

@fjlopez

Description

@fjlopez

Is your feature request related to a problem? Please describe.

Releasing a new version of the SITMUN Application Stack requires updating the version string in many places by hand: backend and proxy build.gradle, both frontend package.json, root and subproject README badges, backend application.yml, API doc YAMLs, frontend environment files, and profile .env files. It’s easy to miss one or get out of sync (e.g. proxy still at 1.2.3 while the rest is 1.2.4). There is no single source of truth, so every release is error-prone and tedious.

Describe the solution you'd like

  • A single source of truth: a root-level VERSION file (one line, e.g. 1.2.4).
  • A script tools/scripts/bump-version.sh that:
    • Propagates the version from VERSION to all consumer files (or, when given a version argument, writes VERSION and then propagates), using targeted match/replace only so we never change dependency versions, protocol versions, or seed data.
    • Supports --dry-run to show every change that would be made without writing anything.
    • Supports --status to report the current version in VERSION and in each consumer file and to flag mismatches.
  • After updating the files, the script runs npm install --package-lock-only in both frontend app dirs so package-lock.json stays in sync.
  • When VERSION does not exist:
    • propagate without version arg → exit 1 with a clear message
    • propagate with version arg → create VERSION and propagate (bootstrap).
  • When npm fails → exit 1 and state that the files were updated but lockfiles were not; suggest manual npm or re-run with the same version.
  • The file list and match/replace patterns should be config-driven (separate data file or one editable block in the script) so that adding a new versioned component only requires adding a config entry, not changing the script’s control flow.

Describe alternatives you've considered

  • Global search-replace of the version string across the repo: too risky (would change dependency versions, WMS/WFS protocol versions, seed schema "version": "1.0", etc.). Prefer one targeted pattern per file type.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions