lzstealth
aafe112c36
Publish Docker Image / build-and-push (./build/Dockerfile, git.lzstealth.com/lzstealth/pulse-signage-web, web) (push) Successful in 1m18s
Publish Docker Image / build-and-push (./build/Dockerfile.player, git.lzstealth.com/lzstealth/pulse-signage-player, player) (push) Successful in 32s
17 lines
1.2 KiB
Markdown
17 lines
1.2 KiB
Markdown
# Repository Instructions
|
|
|
|
## Versioning and releases
|
|
|
|
- Treat `package.json` as the source of truth for the application version.
|
|
- Keep `package.json`, `build/package.player.json`, and `build/package.web.json` on the same version number.
|
|
- Keep dependency versions and package metadata in `package.json`, `package-lock.json`, `build/package.player.json`, and `build/package.web.json` aligned unless a dependency is intentionally omitted from a specific bundle.
|
|
- When changing bundled library versions, update the About page source data from the same package metadata or vendored asset banner rather than hardcoding a fresh literal.
|
|
- When the app version changes, update `CHANGELOG.md` in the same change.
|
|
- Keep database migration versions aligned with the release they actually belong to.
|
|
- If only part of a migration batch belongs to a newer release, split that batch into a separate migration entry instead of relabeling the earlier release.
|
|
- Do not bump migration versions just because the app version changed.
|
|
|
|
## Before finishing a versioned change
|
|
|
|
- Confirm the package version, changelog entry, and migration tags are consistent.
|
|
- If a release note mentions a feature or fix, make sure the matching code path or migration block is tagged to the same release. |