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 >
