Do we still want develop branch?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-11-05 21:10:26

Hi,

The recent case of a commit in develop that was left unmerged to master
made me wondering if people still find the develop branch useful.

Historically (since the SVN days), we used a separate branch for active
development, which we then merged to the stable branch that was used for
creating Boost releases. This allowed to test libraries together before
changes propagate to the stable branch. This was useful back when the
official test matrix was the primary gauge of the Boost "health", so
when something broke, it was rather visible, even if the breakage
manifested in downstream libraries.

With the adoption of git and CI, the relevance of the test matrix has
diminished, and, presumably, people have shifted towards monitoring
their libraries' CI. Which means, people are less likely to notice that
something broke downstream, unless the downstream developer notices and
reports the problem. Although I have been that downstream developer
myself quite a few times, I have to admit that this role of the develop
branch of "an integration testing field" is not well filled in the
current workflow. Noticing the breakage is mostly luck (i.e. a matter of
me making a commit to my library and noticing the CI failure caused by
an upstream dependency) rather than a rule.

Additionally, I have been asked on a few occasions to avoid development
directly in the develop branch and use separate feature branches
instead. That is, do your commits in a feature branch, let the CI pass,
then merge to develop, let the CI pass again, then merge to master.
Apparently, some people are using this workflow by default to avoid
breakage in develop, which means develop is no longer the branch where
the actual development happens.

(This workflow actually makes develop meaningless because your CI over
the feature branch already tests your changes against develop of the
rest of Boost. Which means after merging to develop you're running the
same CI again, and might as well just merge to master straight away.)

Then there's the recurring problem that led to this post - people forget
to merge to master from time to time. Or simply don't have time to
merge. Or the library is no longer actively maintained. Or the commit is
left out of master for any other reason, which means users don't receive
their bug fixes in a release.

Personally, I do try to remember the PRs I make during the release cycle
and look through them just before the release to make sure they are
merged to master. Some of you probably received gentle merge reminders
from me. I'm not sure if anyone else is doing this, but I can say this
is an active mental effort on my part, which I'd rather not have to
make. And even then I can't be sure I remember all PRs or have the time
to cycle though them before the release.

Which brings me to my question. Do people still find the develop branch
useful? Maybe we'd be better off just dropping it and performing all
development in feature branches before merging straight to master?

Also, if you do find develop useful, what do you think about creating a
GitHub Action to automatically merge develop to master once the CI on
develop succeeds? Maybe there are other ideas how to avoid commits
unmerged to master?

Thanks.