Oops, resending from the address that is actually sub'd the the list ... On Mon, 6 Nov 2023 at 19:13, Jonathan Wakely wrote:
On Mon, 6 Nov 2023 at 16:45, Robert Ramey via Boost
wrote: On 11/6/23 1:45 AM, Alexander Grund via Boost wrote:
I agree here that this is a major issue and maybe the release managers can check (e.g. with Peters script) for that common issue and maybe even initiate merges.
Seems to me it would be easy to make a script which the release manager would run before release which would flag all libraries which have unmerged changes on the development branch dated before the current date. This might resolve the whole issue.
That would imply a rule of thumb that develop should (in general) have no changes that aren't merged to master ready for a release.
If you're going to have such a rule, you might as well just get rid of the two branch model and just use a trunk-based git workflow. So you work on develop, and then at some point you create a release branch from develop, call it boost_1_84_0 and that release branch is used for the release. No manual merging from develop to master, because the release branch comes straight from develop, not from an unrelated branch which should (in theory, if the maintainer remembers) match the *content* of develop, but not the actual history of develop.
https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-b... https://www.toptal.com/software/trunk-based-development-git-flow https://trunkbaseddevelopment.com/