Thanks for sharing your thoughts Herve, much appreciated! Completely agree with you that the discussion should have rather focused on the "monolithic vs component-oriented release" subject. Thanks for pointing this out! (I am partly to blame for not capturing the context right.)
Regarding how to tackle website/documentation of multiple components with their own release cycles... Piotr and I have proposals (shared in private with the PMC) on that subject. But we first wanted to have a discussion and consensus on the "monolithic vs component-oriented release" subject, rather than adding one more variable to this intractable equation. On Fri, Sep 1, 2023 at 9:19 AM Herve Boutemy <hbout...@apache.org> wrote: > additional notice: on implementing component-oriented approach > > from a tooling perspective, experience proves that the hard part is not at > Git level, but at generated Maven site level = how to replace a unique > Maven site for the monolithic release with a site that is a combination of > multiple components sites (each with their separate release documentation > history) > > On 2023/09/01 07:09:46 Herve Boutemy wrote: > > it's not "mono vs multi (Git) repo setup" but "monolithic vs > component-oriented release" > > > > longer explanation: > > IMHO, you should frame the discussion about: > > 1. keeping unique global/monolithic release of all log4j > > vs > > 2. splitting log4j into multiple parts/components released separately > (with dependency and compatibility expectations) > > = what is the real change > > > > at Git repo level, implementing the component-oriented strategy can be > done either from one unique Git repo or by multiple Git repos: there are > example of both in the wild, and IMHO the difference at Git level is not > really important > > > > what is important is to define which parts you'll want to release > separately as components > > then define how you'll explain the scope of these parts, and later their > versions and expected compatibility > > = this is where the opportunity is, but hard and impactful decisions > have to be made, and made clear to the whole community > > > > Regards, > > > > Hervé > > > > On 2023/08/31 20:59:32 "Piotr P. Karwasz" wrote: > > > Hi Gary, > > > > > > May I offer a different perspective on this. > > > > > > On Wed, 30 Aug 2023 at 18:56, Gary Gregory <garydgreg...@gmail.com> > wrote: > > > > - I like a mon-repo in general because: > > > > -- Everything is released together with the same version. There is no > > > > mystery of what works with what, what we tested with what. See the > bugs > > > > with Maven plugins mysteriously breaking as counter-examples. > > > > > > While seeing the same version is aesthetically pleasant, we have 4 > > > kinds of users: > > > * library developers will never need anything beyond `log4j-api`, > > > * JUL users will only need `log4j-to-jul`, which declares its > > > `log4j-api` requirement, > > > * same for Logback users, they'll only need `log4j-to-slf4j`, > > > * Log4j Core users **need** to use `log4j-bom` anyway: I have seen > > > several question from Spring Boot users that add the newest version of > > > `log4j-core` to their app and end up with an old (incompatible) > > > version of `log4j-api`, since Spring Boot does version management. > > > > > > > -- A mono-repo gives me the confidence that everything works > *together* because > > > > it was built and tested *together*. > > > > > > In a multi-module setup we would still run e.g. `log4j-cassandra` > > > version 2.20.0 tests against the `log4j-core `2.24.0` snapshot. > > > > > > > -- I or Dependabot can update one Maven property in in my POM for > all of > > > > Log4j and I'm done. > > > > -- I *don't *want a Dependabot PR for each Log4j jar because I use > > > > log4j-api v1, log4j-core v2, log4j-foo v3, log4j-bar v4, log4j-boo > v5, > > > > log4j-arg v6, and so on. > > > > > > If you stick to `log4j-api`, `log4j-bom`, `log4j-to-slf4j` or > > > `log4j-to-jul` above, you would also get just one Dependabot PR. > > > With some improvements to Dependabot, a new release of > > > `log4j-something` and `log4j-bom` might be ignored by Dependabot if it > > > detects that you are not using `log4j-something`. > > > > > > > -- A mono-repo is the lowest barrier to entry for new contributors. > Don't > > > > force me to learn more weird tooling and procedures, Maven and plain > git > > > > are enough magic for anyone. > > > > > > I agree that finding the right repo in a multi-repo project might be > > > challenging. > > > On the other hand from a testing perspective the user does not have to > > > know why a PR on `log4j-core` starts a test suite in another repo. > > > > > > > - I would like to see all modules split up such that there are no > optional > > > > dependencies. I want to be able to depend on a log4j-console for > simple > > > > apps and get a minimal install. > > > > > > I would like that too in 3.x. At my current job the requirement was > > > "having a logging system that prints to a console or a file", so we > > > went with JUL. Of course I switched the backend on my dev box to Log4j > > > Core since debugging using JUL is painful (no proper layout, markers, > > > etc.). > > > > > > > - I am horrified to read "Enables module rot". Hiding a module from > a user > > > > and letting it "rot" is terrible: It is not a development process and > > > > reflects poorly on us IMO. To drop a module, we should: Agree in a > poll or > > > > vote, deprecate it for removal, and then remove it. That's a > process. Not > > > > "Oh, well, it's been rotting on the side over there and it doesn't > work > > > > anymore, oh well! Sorry!" > > > > > > Let's use the term "to retire a module". These are feature stable that > > > have a much slower lifecycle than `log4j-core` and a smaller user > > > base. > > > I would prefer: > > > * to still support these modules, > > > * to have a version number that reflects the actual changes to the > module, > > > * to be able to release them independently if a bug report comes in, > > > * to allow people to relieve us from maintaining these modules, if > > > they work on a day-to-day basis with that technology. E.g. Apache > > > Cassandra might decide to take over `log4j-cassandra` (fork the repo). > > > > > > We are not talking about "hiding" them from the user: one of the > > > projects for next year is to include on our website the generated > > > documentation of every Log4j component that has an enhanced > > > `Log4jPlugins` in its JAR (on a opt-in basis). > > > > > > I have the feeling that we are discussing an X-Y problem: I want to be > > > able to release components independently, so I don't have to release > > > `log4j-core` just because SLF4J released version 2.x or I don't have > > > to delay the release of `log4j-core` because Jackson has a streak of > > > CVEs. I'd like to split the responsibility of releasing a 10M monthly > > > downloads product into more digestible bits. > > > > > > That is why I support multi-repo, because it seems simpler to reach > > > the goal. From a Public Relations perspective I would only like > > > `log4j-api` and the three existing implementations to have separate > > > repos. > > > > > > Piotr > > > > > >
