I am not able to follow. Granted nobody is proposing an ossified BOM that is rarely released, mind explaining why would my statement be an argument against multi release cycles?
Could you give an example of how multi release cycles funnelled through the release of a BOM project will disrupt the workflow of users who only want a single `log4j.version` property in their `pom.xml`? On Sat, 2 Sep 2023, 17:47 Gary Gregory <garydgreg...@gmail.com> wrote: > On Sat, Sep 2, 2023 at 11:39 AM Volkan Yazıcı <vol...@yazi.ci> wrote: > > > Maybe, maybe not. PMC will decide on the release timing of the BOM. > > > > Right, so maybe it's an argument in favor of your point or maybe it's an > argument against! ;-) > > Gary > > > > > > On Sat, Sep 2, 2023 at 2:35 PM Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > > On Sat, Sep 2, 2023 at 6:45 AM Volkan Yazıcı <vol...@yazi.ci> wrote: > > > > > > > > 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`. > > > > > > > > > > So any time you release any jar, the BOM is updated? > > > > > > Gary > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > >
