[log4j] Making Log4j 2 API "the Log4j API"
Given Ralph and Piotr are strongly opinionated about keeping `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x` instead? (We can move the contents of the `spi` package in `log4j-api-3.x` to a separate `log4j-spi` module in `main`.) This will make everything crystal clear: - Log4j 3 is just a major improvement over the backend - Log4j 3 still supports Log4j 2 API - We can move the Log4j 2 API to a separate repository with its own release life cycle (ala SLF4J) - When time comes to make a new Log4j API where PMC agrees to make breaking changes, we can call that one Log4j 3 API I would appreciate it if you can help me to understand if I am missing something. Otherwise, I would like to know why we need to make a major release for a project that is identical to its previous version.
Re: [log4j] Making Log4j 2 API "the Log4j API"
I suspect this won’t work that well once I’ve implemented https://github.com/apache/logging-log4j2/issues/1977 as the current provider SPI is fairly lacking. It might make more sense to release the main API as 3.0.0 and have 2.x depend on the updated API. > On Jan 17, 2024, at 10:11 AM, Volkan Yazıcı wrote: > > Given Ralph and Piotr are strongly opinionated about keeping > `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release > `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x` > instead? (We can move the contents of the `spi` package in `log4j-api-3.x` > to a separate `log4j-spi` module in `main`.) This will make everything > crystal clear: > > - Log4j 3 is just a major improvement over the backend > - Log4j 3 still supports Log4j 2 API > - We can move the Log4j 2 API to a separate repository with its own > release life cycle (ala SLF4J) > - When time comes to make a new Log4j API where PMC agrees to make > breaking changes, we can call that one Log4j 3 API > > I would appreciate it if you can help me to understand if I am > missing something. Otherwise, I would like to know why we need to make a > major release for a project that is identical to its previous version.
Re: [log4j] Making Log4j 2 API "the Log4j API"
Or if we back port any of those changes I’ll propose, then perhaps we can continue with the API at 2.x. That does require that the API target Java 8, though. > On Jan 17, 2024, at 11:32 AM, Matt Sicker wrote: > > I suspect this won’t work that well once I’ve implemented > https://github.com/apache/logging-log4j2/issues/1977 as the current provider > SPI is fairly lacking. It might make more sense to release the main API as > 3.0.0 and have 2.x depend on the updated API. > >> On Jan 17, 2024, at 10:11 AM, Volkan Yazıcı wrote: >> >> Given Ralph and Piotr are strongly opinionated about keeping >> `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release >> `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x` >> instead? (We can move the contents of the `spi` package in `log4j-api-3.x` >> to a separate `log4j-spi` module in `main`.) This will make everything >> crystal clear: >> >> - Log4j 3 is just a major improvement over the backend >> - Log4j 3 still supports Log4j 2 API >> - We can move the Log4j 2 API to a separate repository with its own >> release life cycle (ala SLF4J) >> - When time comes to make a new Log4j API where PMC agrees to make >> breaking changes, we can call that one Log4j 3 API >> >> I would appreciate it if you can help me to understand if I am >> missing something. Otherwise, I would like to know why we need to make a >> major release for a project that is identical to its previous version. >
Re: [log4j] Making Log4j 2 API "the Log4j API"
We can move the spi package content in main to a separate module in main. SPI problem is solved? On Wed, 17 Jan 2024 at 18:33, Matt Sicker wrote: > I suspect this won’t work that well once I’ve implemented > https://github.com/apache/logging-log4j2/issues/1977 as the current > provider SPI is fairly lacking. It might make more sense to release the > main API as 3.0.0 and have 2.x depend on the updated API. > > > On Jan 17, 2024, at 10:11 AM, Volkan Yazıcı wrote: > > > > Given Ralph and Piotr are strongly opinionated about keeping > > `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release > > `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x` > > instead? (We can move the contents of the `spi` package in > `log4j-api-3.x` > > to a separate `log4j-spi` module in `main`.) This will make everything > > crystal clear: > > > > - Log4j 3 is just a major improvement over the backend > > - Log4j 3 still supports Log4j 2 API > > - We can move the Log4j 2 API to a separate repository with its own > > release life cycle (ala SLF4J) > > - When time comes to make a new Log4j API where PMC agrees to make > > breaking changes, we can call that one Log4j 3 API > > > > I would appreciate it if you can help me to understand if I am > > missing something. Otherwise, I would like to know why we need to make a > > major release for a project that is identical to its previous version. > >
Re: [log4j] Making Log4j 2 API "the Log4j API"
That might work, yeah. > On Jan 17, 2024, at 12:46 PM, Volkan Yazıcı wrote: > > We can move the spi package content in main to a separate module in main. > SPI problem is solved? > > On Wed, 17 Jan 2024 at 18:33, Matt Sicker wrote: > >> I suspect this won’t work that well once I’ve implemented >> https://github.com/apache/logging-log4j2/issues/1977 as the current >> provider SPI is fairly lacking. It might make more sense to release the >> main API as 3.0.0 and have 2.x depend on the updated API. >> >>> On Jan 17, 2024, at 10:11 AM, Volkan Yazıcı wrote: >>> >>> Given Ralph and Piotr are strongly opinionated about keeping >>> `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release >>> `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x` >>> instead? (We can move the contents of the `spi` package in >> `log4j-api-3.x` >>> to a separate `log4j-spi` module in `main`.) This will make everything >>> crystal clear: >>> >>> - Log4j 3 is just a major improvement over the backend >>> - Log4j 3 still supports Log4j 2 API >>> - We can move the Log4j 2 API to a separate repository with its own >>> release life cycle (ala SLF4J) >>> - When time comes to make a new Log4j API where PMC agrees to make >>> breaking changes, we can call that one Log4j 3 API >>> >>> I would appreciate it if you can help me to understand if I am >>> missing something. Otherwise, I would like to know why we need to make a >>> major release for a project that is identical to its previous version. >> >>
Re: [log4j] Making Log4j 2 API "the Log4j API"
The quick answer to this question is “I don’t know”. When we first started on the 3.x adventure I can assure you that log4j-api was very different in the 3.x branch because of the changes we needed to make for JPMS and to the build. However, since we have since carried those changes back to 2.x to a large degree it may be that you are correct and we don’t need to create a 3.x version of the API. We would need to compare the two branches of log4j-api and see what the differences are. Ralph > On Jan 17, 2024, at 9:11 AM, Volkan Yazıcı wrote: > > Given Ralph and Piotr are strongly opinionated about keeping > `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release > `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x` > instead? (We can move the contents of the `spi` package in `log4j-api-3.x` > to a separate `log4j-spi` module in `main`.) This will make everything > crystal clear: > > - Log4j 3 is just a major improvement over the backend > - Log4j 3 still supports Log4j 2 API > - We can move the Log4j 2 API to a separate repository with its own > release life cycle (ala SLF4J) > - When time comes to make a new Log4j API where PMC agrees to make > breaking changes, we can call that one Log4j 3 API > > I would appreciate it if you can help me to understand if I am > missing something. Otherwise, I would like to know why we need to make a > major release for a project that is identical to its previous version.
Re: [log4j] Making Log4j 2 API "the Log4j API"
I am afraid I don’t really understand that. How does moving the spine content to another module help? Doesn’t that mean users would now need log4j-api-2.x.jar and log4j-spi-3,x,jar? What is the benefit of that? Ralph > On Jan 17, 2024, at 12:09 PM, Matt Sicker wrote: > > That might work, yeah. > >> On Jan 17, 2024, at 12:46 PM, Volkan Yazıcı wrote: >> >> We can move the spi package content in main to a separate module in main. >> SPI problem is solved? >> >> On Wed, 17 Jan 2024 at 18:33, Matt Sicker wrote: >> >>> I suspect this won’t work that well once I’ve implemented >>> https://github.com/apache/logging-log4j2/issues/1977 as the current >>> provider SPI is fairly lacking. It might make more sense to release the >>> main API as 3.0.0 and have 2.x depend on the updated API. >>> On Jan 17, 2024, at 10:11 AM, Volkan Yazıcı wrote: Given Ralph and Piotr are strongly opinionated about keeping `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x` instead? (We can move the contents of the `spi` package in >>> `log4j-api-3.x` to a separate `log4j-spi` module in `main`.) This will make everything crystal clear: - Log4j 3 is just a major improvement over the backend - Log4j 3 still supports Log4j 2 API - We can move the Log4j 2 API to a separate repository with its own release life cycle (ala SLF4J) - When time comes to make a new Log4j API where PMC agrees to make breaking changes, we can call that one Log4j 3 API I would appreciate it if you can help me to understand if I am missing something. Otherwise, I would like to know why we need to make a major release for a project that is identical to its previous version. >>> >>> >
Re: [log4j] Making Log4j 2 API "the Log4j API"
Now that I have had 10 seconds to think about it. The change to the property syntax and how PropertiesUtil works will create serious problems for what you are proposing. Ralph > On Jan 17, 2024, at 10:02 PM, Ralph Goers wrote: > > The quick answer to this question is “I don’t know”. When we first started on > the 3.x adventure I can assure you that log4j-api was very different in the > 3.x branch because of the changes we needed to make for JPMS and to the > build. However, since we have since carried those changes back to 2.x to a > large degree it may be that you are correct and we don’t need to create a 3.x > version of the API. > > We would need to compare the two branches of log4j-api and see what the > differences are. > > Ralph > >> On Jan 17, 2024, at 9:11 AM, Volkan Yazıcı wrote: >> >> Given Ralph and Piotr are strongly opinionated about keeping >> `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release >> `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x` >> instead? (We can move the contents of the `spi` package in `log4j-api-3.x` >> to a separate `log4j-spi` module in `main`.) This will make everything >> crystal clear: >> >> - Log4j 3 is just a major improvement over the backend >> - Log4j 3 still supports Log4j 2 API >> - We can move the Log4j 2 API to a separate repository with its own >> release life cycle (ala SLF4J) >> - When time comes to make a new Log4j API where PMC agrees to make >> breaking changes, we can call that one Log4j 3 API >> >> I would appreciate it if you can help me to understand if I am >> missing something. Otherwise, I would like to know why we need to make a >> major release for a project that is identical to its previous version. >
