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 > >