> For me, there is one kind of "user" As Piotr indicated we have multiple user groups. As stewards of this project we should take these into account, not just our personal agenda. The current release model where everything shipped all at once doesn't cater for all such use cases.
> For me, there is one kind of "user": a POM that Dependabot can optionally manage We will still ship a BOM module where we share a version composition that is guaranteed to work. Hence, the "user" you mentioned, can still safely rely on *one single* `log4j.version` property in their `pom.xml` and that will still get regularly updated by `dependabot`. Put another way, we won't disrupt the existing consumption method of Log4j. It will keep on working. We will introduce a new possibility: only relying on particular components (e.g., `log4j-api`) and only getting updates when those components *are* really updated. On Fri, Sep 1, 2023 at 11:16 PM Gary Gregory <garydgreg...@gmail.com> wrote: > Hi Piotr, > > Thank you for your detailed response :-) > > My comments are inline below. > > > On Thu, Aug 31, 2023 at 4:59 PM Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > Hi Gary, > > > > May I offer a different perspective on this. > > > > I knew that ;) > > > > > > 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. > > > > I don't think this is relevant IMO. For me, there is one kind of "user": a > POM that Dependabot can optionally manage. Over at Apache Commons, > Dependabot runs on Friday and that's the day I pay attention to such things > (or Saturday AM). Running it every day is not great. It would be nice if > Dependabot could tell you about releases that address CVEs as soon as they > are available. > > > > > > > -- 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. > > > > That's bad in my view, it's confusing as well. > > > > > > > -- 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. > > > > Maybe, maybe not. What module is in what repo is imaginary ATM. > > > > 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`. > > > > "With some improvements to Dependabot..." is an argument against what you > propose. You can't sell me something built with a tool that doesn't exist. > > > > > -- 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. > > > > And imagine the surprise when they break a downstream build they had no > idea existed in the first place. > > > > > - 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.). > > > > Well, there's one thing we can agree on :-) > > > > > > > - 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". > > > Giving it a more polite name does not change anything. I see three states: > Supported, Deprecated, and Removed. > > I'll stop here since I've already expressed my arguments against what's > below. > > Gary > > > > 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 > > >
