Problem
release-please commits version bumps (manifest, pyproject.toml, __init__.py, CHANGELOG) directly to main. With the GitFlow develop → main setup, those commits never flow back to develop, so develop drifts behind on version metadata.
This already happened: after the 0.5.0 release, develop was left at 0.3.0 until a manual main → develop sync. It also caused a wrong version prediction (reading develop's stale manifest instead of main's released state).
Current workaround
Manually run main → develop (fast-forward) after merging each release PR.
Proposed
A workflow that opens (or fast-forwards) a main → develop sync PR when release-please publishes a release, so develop always picks up the bump commits and starts each cycle clean.
Notes
- The default
GITHUB_TOKEN does not chain-trigger workflows, so auto-merging the sync may need a PAT.
- Alternatively, a scheduled or
workflow_dispatch job that fast-forwards develop to main when main is strictly ahead.
Problem
release-please commits version bumps (manifest,
pyproject.toml,__init__.py, CHANGELOG) directly tomain. With the GitFlowdevelop → mainsetup, those commits never flow back todevelop, sodevelopdrifts behind on version metadata.This already happened: after the 0.5.0 release,
developwas left at0.3.0until a manualmain → developsync. It also caused a wrong version prediction (reading develop's stale manifest instead of main's released state).Current workaround
Manually run
main → develop(fast-forward) after merging each release PR.Proposed
A workflow that opens (or fast-forwards) a
main → developsync PR when release-please publishes a release, sodevelopalways picks up the bump commits and starts each cycle clean.Notes
GITHUB_TOKENdoes not chain-trigger workflows, so auto-merging the sync may need a PAT.workflow_dispatchjob that fast-forwardsdeveloptomainwhenmainis strictly ahead.