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 <ralph.go...@dslextreme.com> 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ı <vol...@yazi.ci> 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.
> 

Reply via email to