You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make the release workflow branch-aware so old minor lines can receive
patch releases from their long-lived rel/X.Y.0 maintenance branches,
needed now that we offer LTS support for CN / on-prem deployments.
- master: major/minor only -- creates rel/X.Y.0, merges back, tags vX.Y.0
- rel/X.Y.0: patch only -- bumps and commits onto the branch, tags
vX.Y.Z, with no new branch and no merge back to master
- validation fails fast on wrong branch/bump combinations
Multiple patches accumulate on the same rel/X.Y.0 branch; bump_version.py
increments from the branch's current version (unchanged).
To keep old-line patches from mislabelling the newest release:
- scripts/is_latest_tag.sh reports whether a tag is the highest semver
- build-release.yaml sets make_latest dynamically, so old-line patches
publish to PyPI but produce a non-latest GitHub release
- netlify-deploy.yaml gates the docs deploy on is_latest (manual
workflow_dispatch always deploys), so old-line patches skip docs
MAINTENANCE.md documents the consolidated release flow and the LTS patch
process (fix to master -> cherry-pick onto rel/X.Y.0 -> dispatch patch).
Copy file name to clipboardExpand all lines: MAINTENANCE.md
+21-7Lines changed: 21 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,13 +1,27 @@
1
1
# Repository maintenance and release
2
2
3
3
## How to release
4
-
* manually run [Bump version & trigger release](.github/workflows/bump-version.yaml) workflow
5
-
* after the previous workflow finishes, dispatch the GitHub workflow [Netlify Deploy](.github/workflows/netlify-deploy.yaml) on the `master` branch (takes ~15 minutes)
6
-
* The styling of the documentation is taken from the `master` branch. For more details see [generate.sh](scripts/generate.sh).
7
-
* after the previous workflow finishes, push tag
8
-
* the version should be the same as the one in [Bump version & trigger release](.github/workflows/bump-version.yaml) workflow log
9
-
* checkout latest master branch and tag it `vX.Y.Z`
10
-
* push the tag to the gooddata/gooddata-python-sdk repository (e.g. `git push <remote> vX.Y.Z`)
4
+
5
+
Releases are fully automated by a single workflow dispatch.
6
+
7
+
### Standard release (major / minor)
8
+
1. Manually run the [Release](.github/workflows/bump-version.yaml) workflow on the `master` branch, choosing `major` or `minor`.
9
+
2. That single run bumps the version, creates the long-lived `rel/X.Y.0` maintenance branch, merges back to `master`, and pushes the `vX.Y.0` tag.
10
+
3. The tag push automatically fans out — no manual steps remain:
11
+
*[Build Python Package and Create Release](.github/workflows/build-release.yaml) builds all components, publishes them to PyPI, creates the GitHub release, and notifies Slack.
12
+
*[Netlify Deploy](.github/workflows/netlify-deploy.yaml) rebuilds and deploys the documentation (styling is taken from the `master` branch; see [generate.sh](scripts/generate.sh)).
13
+
14
+
> `patch` is intentionally rejected on `master` — patches are released from the line's `rel/X.Y.0` branch (see below).
15
+
16
+
### Releasing an LTS patch (patching an old version)
17
+
Old minor lines (e.g. for CN / on-prem LTS support) are patched from their long-lived `rel/X.Y.0` maintenance branch:
18
+
1. Merge the fix to `master` via a normal PR.
19
+
2. Cherry-pick the fix onto the target `rel/X.Y.0` branch.
20
+
3. Run the [Release](.github/workflows/bump-version.yaml) workflow with the branch selector set to `rel/X.Y.0` and `bump_type = patch` (only `patch` is accepted on `rel/*`).
21
+
4. The workflow bumps the patch on that branch (e.g. `1.5.0` → `1.5.1`), commits it onto `rel/X.Y.0`, and pushes the `vX.Y.Z` tag. It does **not** create a new branch or merge to `master`.
22
+
5. The tag publishes every component to PyPI and creates a **non-latest** GitHub release. Documentation is intentionally **not** redeployed for old-line patches.
23
+
24
+
Subsequent patches repeat steps 1-4 on the same `rel/X.Y.0` branch; each reads the branch's current version and increments the patch component (`1.5.1` → `1.5.2` → …).
0 commit comments