Re: Do we still want develop branch?

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2023-11-06 09:45:28

Am 06.11.23 um 01:09 schrieb Robert Ramey via Boost:
> I doubt that the serialization library is the only one with this issue.
Most libraries have passing CI on multiple CI providers and we (Boost 
devs) work together helping each other in most cases.
We have Boost.CI which has templates that are updated when common issues 
are found so other Boost devs can just C&P that update into their scripts.
> The sadist part of all this is that even if it did "work" it would 
> still be useless.  It's not uncommon for a large and/or complex 
> library to fail one or more tests on one or more compilers due to 
> issues in the compiler itself.  These can't be "fixed" in the 
> library.  The test matrix shows all the tests x all the environments.  
> One can easily see if any failure is general or isolated to a 
> particular environment.
That is true. But I'd consider this one big advantage of Boost that it 
has workarounds in place for many compiler deficits such that Boost 
works in more environments and even with compiler bugs than other projects.
> The output of the CI is very user unfriendly.
How so? It is a nice list with a red or green mark next to a short 
description of the configuration (e.g. OS, compiler version, CXX 
standard) and has the full logs
The test matrix on the other hand is missing easy access to logs and 
feedback on changes not yet merged to develop but merging without 
extensive tests risks breaking downstream libraries.
> A useful observation.  The problem is that the current CI tests the 
> development branch of one's library agains the develop branch of all 
> the other libraries.  So now my library looks like it "works" but when 
> (and only when) it could fail when run against all master branches.  
> So the testing shows pass when it actually fails when shipped with the 
> master. Note that as we speak the test matrix for the master branch 
> isn't working so it seems we never test the software which is actually 
> being shipped.
The same CI runs against master branch for pushes or merges of/to master
I tend to actually open a a PR from develop to master to verify nothing 
will be broken on master after the merge.
> I see the merit in this observation.  Personally, on my own machine, I 
> test my development or feature branch agains the master branch of all 
> the other libraries.  It's the only way to know that when the changes 
> are merged into the master the software will still work.
See above: It is useful but not the only way and limitted in scope (not 
as many compilers/configurations tested as e.g. the Boost.CI template does)
>> 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.
> Right

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.

I do see a value in having a separate develop and master branch: During 
release cycles you can continue working on develop while master is 
frozen for the ongoing release.
Besides that it is true that feature branches should be enough and 
develop could be removed.

Alex