2025年9月12日(金) 6:00 Vinnie Falco <vinnie.falco@gmail.com>:
My opinion, this needs to be split up physically into individual libraries so they can each evolve and be maintained independently (or not maintained, such as in the case of old X3 maybe?)
At least 3 members: Peter Dimov, Joel de Guzman and Nana Sakisaka have reached a strong consensus on splitting Spirit subcomponents into 3 distinct repositories. https://github.com/boostorg/spirit/issues/795#issuecomment-3276591805 2025年9月12日(金) 6:26 Nana Sakisaka <aroma.slope.seven@gmail.com>:
2025年9月12日(金) 6:00 Vinnie Falco <vinnie.falco@gmail.com>:
On Thu, Sep 11, 2025 at 1:41 PM Nana Sakisaka < aroma.slope.seven@gmail.com> wrote:
There is a long-standing request to make the X3 docs more "visible" to users
Oh... yes, that is a problem. I myself did not realize that Spirit was actually three separate libraries, and that the move to C++23 only affected one of them (?)
My opinion, this needs to be split up physically into individual libraries so they can each evolve and be maintained independently (or not maintained, such as in the case of old X3 maybe?)
Spirit consists of 3 individual libraries: - Spirit.Classic, dormant for 20 years, supports C++03. - Spirit.V2 (Qi & Karma & Lex), not actively maintained, supports C++11. - Spirit.X3, technically being the primary development target since 2014; supports C++23 & C++26.
The recent breakage only affects the `develop` branch of Spirit.X3 only.
We have been working on supporting the Asciidoctor and Antora toolchains to provide a modern option for Boost library documentation, as the current Quickbook is receiving little maintenance (in some cases no maintenance). Quickbook is a long-term existential risk for Boost library documentation. Antora looks like this (with our custom UI and stylesheets):
I have professional skills on AsciiDoc and I actually plan to migrate the entire Spirit documentation to AsciiDoc. Although we haven't made a consensus on which framework to choose, I believe AsciiDoc is the best and I plan to submit PR.
You have my word on this, it's one of my initial motivations for volunteering to become the maintainer in the first place. https://github.com/boostorg/spirit/issues/800#issuecomment-2857784154 Despite that I posted a rather strong comment, Joel accepted me to become the maintainer and I'm willing to fulfill my responsibility for that.
I apologize if I came across as heavy handed in some of those issues. I
think the problem here is that months of changes and intentions which impact other things came out of nowhere. Perhaps when a new maintainer is appointed for a library there could be a formal introduction to the mailing list, and the new maintainer receives some kind of instruction so they can learn about customs such as the mailing list, the desire to avoid breaking existing users, and the encouragement to maintain a two-way dialog when making big changes. Maybe it is not too late to do this?
I believe the actual problem is that almost every open source developers naturally has the instinct that the GitHub repository is the primary place for such technical discussion. I honestly think that every developer who is affected by the breaking changes on the **`develop`** branch should immediately subscribe to the repository and post a comment on the PR.
Vinnie, IIRC you were one of the modern developers who disliked the mailing list interface, no? I personally never use email during my OSS work except for Boost. Don't you feel stressed by this interface? I assume that's why you repeatedly promote Slack. I don't like this email interface at all. I broke the silence after 10 years of subscription because Vinnie mentioned my name on the list. (No offense. I think it was the right timing.)