There is a difference between a user’s compile failing vs the build having 
changed.  Given how old log4cxx is I would expect it to be used in a fair 
number of places despite its version number. I haven’t looked at the code 
myself but is there no way to keep it backward compatible while also keeping 
the new changes?

Ralph

> On Mar 2, 2020, at 6:48 AM, Thorsten Schöning <tschoen...@am-soft.de> wrote:
> 
> Guten Tag Stephen Webb,
> am Montag, 2. März 2020 um 12:45 schrieben Sie:
> 
>> The issue is it has changed to core log4cxx api so that existing 0.10 code
>> may not compile.
>> The macros are the core log4cxx api.
> 
> AFAIK there are no commitments to a stable API anyway, the version
> number itself doesn't make such a claim, there are other patches
> applied already which change the API in theory as well to e.g. fix
> memory leaks, additional changes are in the pipeline in theory
> switching things again to use smart pointers etc.
> 
> So I don't get your point: Changing the core is not a problem in
> general. Keeping things somewhat backwards compatible might be kept
> in mind of course, but you don't seem to have any concrete problem
> currently anyway. I suggest testing things first and discuss problems
> as they arise. Even though that might mean that you might need to
> adopt your code base, as others did already as well.
> 
> Remember that you removed ANT-support in favour of CMAKE, even though
> someone might still rely on ANT. Things simply change sometimes...
> 
> Mit freundlichen Grüßen,
> 
> Thorsten Schöning
> 
> -- 
> Thorsten Schöning       E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme      http://www.AM-SoFT.de/
> 
> Telefon...........05151-  9468- 55
> Fax...............05151-  9468- 88
> Mobil..............0178-8 9468- 04
> 
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
> 
> 


Reply via email to