additional notice: on implementing component-oriented approach

from a tooling perspective, experience proves that the hard part is not at Git 
level, but at generated Maven site level = how to replace a unique Maven site 
for the monolithic release with a site that is a combination of multiple 
components sites (each with their separate release documentation history)

On 2023/09/01 07:09:46 Herve Boutemy wrote:
> 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
> > 
> 

Reply via email to