on Mon Oct 21 2013, Daryle Walker
Since a project that’s made of a bunch of sub-repositories that’s later merged is (AFAIK) unusual, I don’t think the writer of gitflow had it in mind.
I’m guessing that each sub-repository independently uses gitflow. When it’s shipping time, the release-merge script grabs from the “master” branch of each sub-repository. Of course, this doesn’t cover multiple libraries that have to work together or what happens when fixing is necessary (probably due to cross-library problems).
And do the test runners work off “develop,” “master,” “release,” or does it shift depending where we are in the release cycle?
Ideally, we'd test everything, in this priority order: master release/v<version> develop
Sent from Windows Mail
From: Peter Dimov Sent: Monday, October 21, 2013 10:16 AM To: Boost Dev-List
Dave Abrahams wrote:
IIUC we already agreed long ago to use gitflow:
It's not entirely clear to me what using gitflow would mean in the context of a Boost superproject with per-library submodules. Who is "we" who would be using gitflow, the Boost release managers or the library maintainers?
Both
When Boost release 1.64.0 is started, who is going to create the gitflow release branch,
A Boost release manager
and from what?
From the "master" branch of the top-level Boost repository
-- Dave Abrahams