On 4/10/25 1:57 PM, Andrey Semashev via Boost wrote:
On 10 Apr 2025 23:38, Robert Ramey via Boost wrote:
Sometime ago someone made the case that we should drop the Debug branch in the git storage for the libraries. I found the case pretty convincing and endorsed the change. However, it seems that the idea was not well received and the idea was not adopted. I hope my endorsement wasn't responsable for it's being dismissed.
Now it seems that the idea HAS been adopted. I've found in both the libraries I maintain, some "maintainers" check into the master branch directly from a feature branch used for debugging. This was kind of problematic as the debug and master branch were no longer easily understood by doing a diff. Worse, other "maintainers" check into the debug branch in the traditional way leaving the merge to master as a separate operation in the traditional manner. My custom has been to merger to master just before the next release.
I only dip into maintenance occasionally, so I don't remember all the details and I have to spend a lot of time looking at who did what. So, I'm announcing that I am unilaterally declaring soon I will be leaving the debug branch aside and not use it in the future. Those who have the authority to directly make changes in these libraries (as opposed do making a merge request) should know that any pushes to the debug branch will be lost.
First, I'm assuming you mean the develop branch, not debug.
Right
Second, the two branches are referenced by the superproject and therefore are used by all submodules, including those which are not maintained by you. If you stop updating develop, this will eventually affect any downstream libraries, potentially breaking them.
True. On my own system, I've dropped testing against other libraries which are not on the master branch. That is, I set all the boost libraries excepting my own to master branch. This is because I spent way too much time trying to test something in my own library which I ended up having to track down into some other library which was in a state of flux due to being on the develop branch. A huge waste of time. By doing this way, I had the confidence that when my library was updated in the master, it was effectively testing against the next release rather than the last one. This eliminated occasional problems which consumed disproportional amount of time to sort out.
If this is your intention (is it?) then I guess this signals downstream libraries to stop depending on your libraries.
LOL - it signals downstream libraries that they are I'm not sure how it
affects the superproject and the release procedure, but it raises the question of whether the libraries should stay in Boost in this state or be eventually removed (which would be unfortunate).
Since we have no usage statistics for individual libraries, we have no way of knowing which libraries we should prioritize. It raises the question as to what utility the develop branch provides.
I'm curious, what is the problem with develop are you facing that warrants such a change?
see above. It's mostly a problem because I only engage in library maintenance occasionally. And truth is I forget a lot of stuff in the meantime. I'm also not a git guru (and hardly a git hacker!) which also means an amount of wasted time. I've totally given up trying to understand B2 and I never touch the jam files so at least that's not a problem. I do think we would be better served by shifting more to the feature branch way of doing things. Once one does this, the develop branch become superfluous. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost