On 12/8/20 3:04 AM, Neil C Smith wrote:
- It seems managing the master, delivery and release branches worked
well without headache or too much overhead. I'd thank the contributors
to play well with the rules and supporting my requests. It is about 40+
PR got merged into master while we were still working on the release
stabilization.
Yes, seems to have been a really good solution! Any issues on your
end in merging delivery branch? Any PRs actually held up from merging
to master?
The only issue I had was probably the GitHub UI. at the beginning I've
created two PR-s from delivery to the master and release122 branch, to
track the changes. It was working, but when I merged the PR-s and wanted
to create a similar set for beta3 the content of the PR went weird. So
from that point, however it is not ideal, I did the merges locally from
command line, which worked well. It was probably one time I had to
resolve a conflict on the manifest version, but that was trivial.
Temporary delivery branch just an artefact of our current build
process, or actually useful to keep in the process?
That's really temporal, I'm about to delete it, in order to prevent some
confusion. It is not really part of the build process either. But if
we'd follow this model. The 'delivery' or find a better name for that
branch, has to be recreated from master on branching of 12.3.
