[sane-devel] [janitorial] Upcoming release: 1.0.29
skelband at gmail.com
Thu Dec 19 20:34:30 GMT 2019
On Thu, Dec 19, 2019 at 11:27 AM Rolf Bensch <rolf at fam-bensch.de> wrote:
> gitflow suggests to create a release branch (here: release/1.0.29) at
> feature freeze and merge it back to develop (in our case: master) after
> the release has been tagged published.
> gitflow suggests to merge releases into master branch and doing all
> other work in a develop branch with separate feature branches (we
> already started using some). We don't need the future release stuff and
> hotfixing old releases. Only 3 main branches: master for the merged
> releases, develop with it's feature branches and from time to time a new
> release branch, started from recent develop. This is what we're doing at
> Indeed this is a similar workflow that we use where I work, although we
We have a default branch for our current dev work, and a separate release
Before release, we merge default into a separate long-lived release branch
at the start of code freeze.
Any changes committed to default are grafted into the release branch if
they are to be added to the release, normally just bug fixes, no new
At release time, a release is created from the head of the release branch,
release branch is merged back into default.
New features are developed on a separate "feature branch" which is merged
back into default.
That's a typical mercurial work flow, and IIUC that is similar to what is
proposed here and it works well for us.
We generally do have a more "curated" release though, rather than "whatever
is current in default at the time".
It is often the same, but not necessarily. That curation is managed by
deciding the timing of feature branch merge.
If the feature is not ready for the release, the merge back into default is
My 2c :D
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sane-devel