Re: Do we still want develop branch?

From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2023-11-10 23:38:46

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 <boost_at_[hidden]>
> 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-based-development
> https://www.toptal.com/software/trunk-based-development-git-flow
> https://trunkbaseddevelopment.com/
>
>