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
