Re: Mono-vs-Multi repo setup
Hi Herve, On Fri, 1 Sept 2023 at 09:10, Herve Boutemy wrote: > > it's not "mono vs multi (Git) repo setup" but "monolithic vs > component-oriented release" Thanks for putting the discussion back on track. I think we could look at what other logging frameworks do. Ceki's SLF4J/Logback has: * one monolithic release for SLF4J + bindings to generation 1 logging backends; this really bugs me, since some (most?) releases only update the obsolete bindings, * one monolithic release for Logback. On the other hand James' JBoss Logging/LogManager has a separate release for each component. If we decide to split `log4j-api` into its own repo (let's say for 3.x) and have a separate release cycle: * we can safely split the two implementations `log4j-to-jul` and `log4j-to-slf4j` into their own repos/lifecycle, * we can safely split all the bridges into their own repos/lifecycle; remark that `log4j-jpl` should probably have been in its own repo from the beginning, since it even has a different Java version requirement, * `log4j-1.2-api` and `log4j-web` are partially joined at the hip with `log4j-core`, although their main functionality is independent. * all the remaining modules depend on the **internal** API of `log4j-core`. They could stay in the current repo. The way I see it, if one of the modules that depend only on the `log4j-api` needs a fix to work with a newer API, we messed up something. The modules that stay with `log4j-core` would still have a coordinated lifecycle, but we probably still need a separate repo/Maven module to test that everything works together. E.g. I am not entirely sure that someone can use `log4j-cassandra` together with `log4j-flume-ng`: their dependencies have incompatible Guava requirements and I don't know if our modules don't use Guava transitively. Piotr
Re: Mono-vs-Multi repo setup
> 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 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 > wrote: > > > Hi Gary, > > > > May I offer a different perspective on this. > > > > I knew that ;) > > > > > > On Wed, 30 Aug 2023 at 18:56, Gary Gregory > 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 terr
Re: Mono-vs-Multi repo setup
On Sat, Sep 2, 2023 at 8:35 AM Gary Gregory wrote: > On Sat, Sep 2, 2023 at 6:45 AM Volkan Yazıcı 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? > updated -> released Gary > > 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 >> 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 >> > 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 suc
Re: Mono-vs-Multi repo setup
On Sat, Sep 2, 2023 at 6:45 AM Volkan Yazıcı 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 > 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 > > 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
Re: Mono-vs-Multi repo setup
Maybe, maybe not. PMC will decide on the release timing of the BOM. On Sat, Sep 2, 2023 at 2:35 PM Gary Gregory wrote: > On Sat, Sep 2, 2023 at 6:45 AM Volkan Yazıcı 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 > > 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 > > > 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. > > > > > > > >
Re: Mono-vs-Multi repo setup
On Sat, Sep 2, 2023 at 11:39 AM Volkan Yazıcı 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 > wrote: > > > On Sat, Sep 2, 2023 at 6:45 AM Volkan Yazıcı 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 > > > 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 > > > > > 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 barr
Re: Mono-vs-Multi repo setup
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 wrote: > On Sat, Sep 2, 2023 at 11:39 AM Volkan Yazıcı 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 > > wrote: > > > > > On Sat, Sep 2, 2023 at 6:45 AM Volkan Yazıcı 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 > > > > > 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-ar
