On 11/10/23 3:58 PM, Peter Dimov via Boost wrote:

The idea of the current model is that master is the release-ready branch at all times, and develop is the unstable branch that may or may not be in a good state.

Branching off for release from an unstable branch made releases unpredictable, there was no way to tell how long the release branch would take to stabilize.

Right.

In principle we can switch to a model where we have no develop, master is, as now, stable and release-ready at all times (at least in theory), and all development happens on feature branches. This works for independent libraries,

but integration testing has to happen somewhere. Currently it happens on develop (at least in theory.)

If can test the feature branch of one library X against the master branch of all the other libraries before me merge the feature branch into the master, then no "integration testing" should be necessary. Of course, it doesn't quite work that way in practice as some libraries don't test their whole public API and sometimes make a mistake which can break a dependent library. So an "integration test" will have to be done from time to time - especially before release. Fortunately we already have that in the current test matrix. So I support the elimination of the develop branch in Boost. Personally, I would maintain my own develop branch of the serialization library on my personal machine. When it passes all my tests locally I can merge to master. This would be used to small dumb tweaks which are the majority of the changes I make these days. For fixing a real bug or adding something to the API, I'd use the normal feature branch approach. Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 11/11/23 3:12 PM, Peter Dimov via Boost wrote:

Robert Ramey wrote:

...

If can test the feature branch of one library X against the master branch of all the other libraries before me merge the feature branch into the master, then no "integration testing" should be necessary.

This doesn't work if you want to take advantage of a new feature in library Y that hasn't been merged to master yet, because it's still in development.

I can't see why one would ever want to do that. Who injects untested code from other libraries into his own library- or application for that matter. That's just asking for trouble, not to mention chaos.

(It also doesn't work well if your change breaks other libraries. They'll only know it after you merge to master.)

Right. I acknowledged that above. That's what the current test matrix does.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 11/11/23 5:29 PM, Peter Dimov via Boost wrote:

Robert Ramey wrote:

...

I can't see why one would ever want to do that.

Often because the feature has been developed at their request, and they don't want to wait for the next Boost release to take advantage of it.

They wouldn't have to wait until the next release. Any such feature would be merged into the master as soon as it was done/ready.

This also works in the other direction, for features being deprecated and removed - fixing the deprecation warnings should be done sooner than later,

As they would be under the new system.

because our users aren't particularly impressed if our own libraries emit warnings because they use deprecated features of other Boost libraries.

Right. Under the new system they would find out at the earliest possible time.

For the user, Boost is a whole,

That's an interesting perspective. I'm still attached to the "modular" boost idea where each library + it's dependencies stands (mostly) independent from the rest of boost. and it should keep its house in order.

which we're trying to do. Broadening the concerns and responsibilities of each library developer to include all of boost doesn't scale and makes library development a lot harder. This really is a disincentive to contribute to boost in the first place. Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Vinnie Falco via Boost said: (by the date of Sun, 12 Nov 2023 07:52:46 -0800)

Why is this ridiculous conversation "Do we still want develop branch" still raging?

And what was the decision: yes or no? Will there be a vote? -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdansk University of Technology (Gdansk Tech) Faculty of Applied Physics and Mathematics Institute of Physics and Applied Computer Science Division of Theoretical Physics and Quantum Information -- http://yade-dem.org/ http://pg.edu.pl/p/jan-kozicki-19725 http://mostwiedzy.pl/en/jan-kozicki,19725-1

On 11/12/23 9:40 AM, Andrey Semashev via Boost wrote:

On 11/12/23 19:06, Janek Kozicki via Boost wrote:

To be clear, the original point of this topic was to hear people's opinion on the develop branch usefulness. This wasn't a vote or proposal to remove it.

I didn't see this distinction. But now you've heard various opinions, perhaps you might want to turn it into a proposal. Which might be interesting. The acceptance/implementation of build practices in boost is pretty murky as far as I can tell. That is, I've never really understood it. Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

That's an interesting perspective. I'm still attached to the "modular" boost idea where each library + it's dependencies stands (mostly) independent from the rest of boost.

I am too. Modular consumption of Boost will have to be the future of Boost as we continue to accept and grow the collection of libraries. In the past, distribution of software was more difficult than it is today so shipping the entire still-somewhat-small Boost bundle was tenable. But nowadays, we have vcpkg and CMake's dependency providers and even more Boost libraries than ever. To help us meet contemporary expectations, Boost must become modular to survive. Luckily the vcpkg devs have solved this for us already. As for the utility of a develop branch, I think of it more as a nightly branch where stable-but-not-master-stable code lives. To me, feature branches are useful with a develop branch. For what it's worth, part of me actually enjoys fixing bugs in other Boost libraries. As Boost developers, I feel a sense of fraternity and as such, one must always look out for their fellow Boost bros. - Christian

On 11/12/23 18:52, Vinnie Falco via Boost wrote:

Why is this ridiculous conversation "Do we still want develop branch" still raging?

You are free to ignore any conversation you find uninteresting or ridiculous.