Re: [log4cxx] Towards a release
Guten Tag Stephen Webb, am Montag, 30. März 2020 um 08:47 schrieben Sie: > I see no question at that link, only the commit diff. Please try again and have a look at the far right in the dot-menu, at the same line like the file name. There's an option to show comments or not, which might be disabled for you. Anyway, I added a comment as well. 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
Re: [log4cxx] Towards a release
I see no question at that link, only the commit diff. On Mon, Mar 30, 2020 at 5:36 PM Thorsten Schöning wrote: > Guten Tag Stephen Webb, > am Montag, 30. März 2020 um 04:19 schrieben Sie: > > > My PR#21 (https://github.com/apache/logging-log4cxx/pull/21) remains > > un-reviewed. > > It's not, I already asked questions weeks ago: > > > https://github.com/apache/logging-log4cxx/pull/21/files/63a6fd31ddf27ba05c76bc3e6b1506e28f55b7c0..1190a41281e4f925341a0c4120f34b69f13ce43a#diff-06a664097df306d4e6937bbe0d30b4f1 > > Didn't you get any notification or can't see it? > > 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
Re: [log4cxx] Towards a release
Guten Tag Stephen Webb, am Montag, 30. März 2020 um 04:19 schrieben Sie: > My PR#21 (https://github.com/apache/logging-log4cxx/pull/21) remains > un-reviewed. It's not, I already asked questions weeks ago: https://github.com/apache/logging-log4cxx/pull/21/files/63a6fd31ddf27ba05c76bc3e6b1506e28f55b7c0..1190a41281e4f925341a0c4120f34b69f13ce43a#diff-06a664097df306d4e6937bbe0d30b4f1 Didn't you get any notification or can't see it? 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
Re: [log4cxx] Towards a release
At least one log4cxx user has been using my fork of log4cxx (which includes PR#21) to build on Windows (see https://github.com/microsoft/vcpkg/issues/6125) On Mon, Mar 30, 2020 at 2:35 PM Ralph Goers wrote: > I’d be happy to merge it if someone involved with the project (even a > non-committer) can look at it. I don’t normally work on Windows so trying > to run a build with it is a bit more than I would like to do. > > Ralph > > > On Mar 29, 2020, at 7:19 PM, Stephen Webb wrote: > > > > Is there anyway I can to help move this forward (I do not have an Apache > > account)? > > > > My PR#21 (https://github.com/apache/logging-log4cxx/pull/21) remains > > un-reviewed. > > > > I have created a migration tool > > https://github.com/stephen-webb/log4cxx_10_to_11 for anyone who has the > > same migration issues as I. > > > > Regards > > Stephen Webb > > > > > > > > On Wed, Mar 4, 2020 at 3:16 AM Tobias Frost wrote: > > > >> On Tue, Mar 03, 2020 at 04:51:28PM +1100, Stephen Webb wrote: > >> > >>> I would be surprised if any unix distribution would change to 0.11 > >> log4cxx > >>> if its API is incompatible with 0.10. > >> > >> With my Debian maintainer hat on: > >> This is nothing special and day to day businesss with distos: > >> > >> It will "just" invoke a library transition [1], and the new binary > >> packages will be named according to the new SONAME, e.g liblog4cxx11 > >> After the transition the old library version will be removed from > >> Debian. > >> > >> Frankly, I'm really looking forward to have a new liblog4cxx for > >> Debian, and now (as we are still some time away from the next Debian > >> release) would be absolutly the best time for a new release. > >> The new version just fixes so many issues that it really pays off the > >> extra work for packaging and the transtion, introduced by the SONAME > >> bump. (my 2cent…) > >> > >> -- > >> Cheers, > >> tobi > >> > >> [1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions > >> > >>> Regards > >>> Stephen Webb > >>> > >>> > >>> > >>> On Tue, Mar 3, 2020 at 4:28 AM Thorsten Schöning < > tschoen...@am-soft.de> > >>> wrote: > >>> > Guten Tag Ralph Goers, > am Montag, 2. März 2020 um 16:34 schrieben Sie: > > > There is a difference between a user’s compile failing vs the build > > having changed. > > And which? Things don't work in the worst case either way and need to > be adopted. Why exactly is getting rid of build support by ANT > acceptable for users relying on that, but applying LOGCXX-319 might(!) > not be? > > If I remember correctly, the concrete changes could even be adopted > using automatic search > > > Given how old log4cxx is I would expect it to be > > used in a fair number of places despite its version number. > > And a fair number of users applied either the available patches > already since the last release or simply work with master already > anyway. I can't remember anyone complaining about the changes > introcuded by that concrete issue in the last years as well. > > > I > > haven’t looked at the code myself but is there no way to keep it > > backward compatible while also keeping the new changes? > > In my opinion this is an unnecessary meta-discussion until a concrete > problem has been described introduced by LOGCXX-319 or other changes. > So at least I won't reconsider each and every change since the last > release. > > 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 > > > >> > > >
Re: [log4cxx] Towards a release
I’d be happy to merge it if someone involved with the project (even a non-committer) can look at it. I don’t normally work on Windows so trying to run a build with it is a bit more than I would like to do. Ralph > On Mar 29, 2020, at 7:19 PM, Stephen Webb wrote: > > Is there anyway I can to help move this forward (I do not have an Apache > account)? > > My PR#21 (https://github.com/apache/logging-log4cxx/pull/21) remains > un-reviewed. > > I have created a migration tool > https://github.com/stephen-webb/log4cxx_10_to_11 for anyone who has the > same migration issues as I. > > Regards > Stephen Webb > > > > On Wed, Mar 4, 2020 at 3:16 AM Tobias Frost wrote: > >> On Tue, Mar 03, 2020 at 04:51:28PM +1100, Stephen Webb wrote: >> >>> I would be surprised if any unix distribution would change to 0.11 >> log4cxx >>> if its API is incompatible with 0.10. >> >> With my Debian maintainer hat on: >> This is nothing special and day to day businesss with distos: >> >> It will "just" invoke a library transition [1], and the new binary >> packages will be named according to the new SONAME, e.g liblog4cxx11 >> After the transition the old library version will be removed from >> Debian. >> >> Frankly, I'm really looking forward to have a new liblog4cxx for >> Debian, and now (as we are still some time away from the next Debian >> release) would be absolutly the best time for a new release. >> The new version just fixes so many issues that it really pays off the >> extra work for packaging and the transtion, introduced by the SONAME >> bump. (my 2cent…) >> >> -- >> Cheers, >> tobi >> >> [1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions >> >>> Regards >>> Stephen Webb >>> >>> >>> >>> On Tue, Mar 3, 2020 at 4:28 AM Thorsten Schöning >>> wrote: >>> Guten Tag Ralph Goers, am Montag, 2. März 2020 um 16:34 schrieben Sie: > There is a difference between a user’s compile failing vs the build > having changed. And which? Things don't work in the worst case either way and need to be adopted. Why exactly is getting rid of build support by ANT acceptable for users relying on that, but applying LOGCXX-319 might(!) not be? If I remember correctly, the concrete changes could even be adopted using automatic search > Given how old log4cxx is I would expect it to be > used in a fair number of places despite its version number. And a fair number of users applied either the available patches already since the last release or simply work with master already anyway. I can't remember anyone complaining about the changes introcuded by that concrete issue in the last years as well. > I > haven’t looked at the code myself but is there no way to keep it > backward compatible while also keeping the new changes? In my opinion this is an unnecessary meta-discussion until a concrete problem has been described introduced by LOGCXX-319 or other changes. So at least I won't reconsider each and every change since the last release. 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 >>
Re: [log4cxx] Towards a release
Is there anyway I can to help move this forward (I do not have an Apache account)? My PR#21 (https://github.com/apache/logging-log4cxx/pull/21) remains un-reviewed. I have created a migration tool https://github.com/stephen-webb/log4cxx_10_to_11 for anyone who has the same migration issues as I. Regards Stephen Webb On Wed, Mar 4, 2020 at 3:16 AM Tobias Frost wrote: > On Tue, Mar 03, 2020 at 04:51:28PM +1100, Stephen Webb wrote: > > > I would be surprised if any unix distribution would change to 0.11 > log4cxx > > if its API is incompatible with 0.10. > > With my Debian maintainer hat on: > This is nothing special and day to day businesss with distos: > > It will "just" invoke a library transition [1], and the new binary > packages will be named according to the new SONAME, e.g liblog4cxx11 > After the transition the old library version will be removed from > Debian. > > Frankly, I'm really looking forward to have a new liblog4cxx for > Debian, and now (as we are still some time away from the next Debian > release) would be absolutly the best time for a new release. > The new version just fixes so many issues that it really pays off the > extra work for packaging and the transtion, introduced by the SONAME > bump. (my 2cent…) > > -- > Cheers, > tobi > > [1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > > Regards > > Stephen Webb > > > > > > > > On Tue, Mar 3, 2020 at 4:28 AM Thorsten Schöning > > wrote: > > > > > Guten Tag Ralph Goers, > > > am Montag, 2. März 2020 um 16:34 schrieben Sie: > > > > > > > There is a difference between a user’s compile failing vs the build > > > > having changed. > > > > > > And which? Things don't work in the worst case either way and need to > > > be adopted. Why exactly is getting rid of build support by ANT > > > acceptable for users relying on that, but applying LOGCXX-319 might(!) > > > not be? > > > > > > If I remember correctly, the concrete changes could even be adopted > > > using automatic search > > > > > > > Given how old log4cxx is I would expect it to be > > > > used in a fair number of places despite its version number. > > > > > > And a fair number of users applied either the available patches > > > already since the last release or simply work with master already > > > anyway. I can't remember anyone complaining about the changes > > > introcuded by that concrete issue in the last years as well. > > > > > > > I > > > > haven’t looked at the code myself but is there no way to keep it > > > > backward compatible while also keeping the new changes? > > > > > > In my opinion this is an unnecessary meta-discussion until a concrete > > > problem has been described introduced by LOGCXX-319 or other changes. > > > So at least I won't reconsider each and every change since the last > > > release. > > > > > > 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 > > > > > > >
Re: [log4cxx] Towards a release
On Tue, Mar 03, 2020 at 04:51:28PM +1100, Stephen Webb wrote: > I would be surprised if any unix distribution would change to 0.11 log4cxx > if its API is incompatible with 0.10. With my Debian maintainer hat on: This is nothing special and day to day businesss with distos: It will "just" invoke a library transition [1], and the new binary packages will be named according to the new SONAME, e.g liblog4cxx11 After the transition the old library version will be removed from Debian. Frankly, I'm really looking forward to have a new liblog4cxx for Debian, and now (as we are still some time away from the next Debian release) would be absolutly the best time for a new release. The new version just fixes so many issues that it really pays off the extra work for packaging and the transtion, introduced by the SONAME bump. (my 2cent…) -- Cheers, tobi [1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions > Regards > Stephen Webb > > > > On Tue, Mar 3, 2020 at 4:28 AM Thorsten Schöning > wrote: > > > Guten Tag Ralph Goers, > > am Montag, 2. März 2020 um 16:34 schrieben Sie: > > > > > There is a difference between a user’s compile failing vs the build > > > having changed. > > > > And which? Things don't work in the worst case either way and need to > > be adopted. Why exactly is getting rid of build support by ANT > > acceptable for users relying on that, but applying LOGCXX-319 might(!) > > not be? > > > > If I remember correctly, the concrete changes could even be adopted > > using automatic search > > > > > Given how old log4cxx is I would expect it to be > > > used in a fair number of places despite its version number. > > > > And a fair number of users applied either the available patches > > already since the last release or simply work with master already > > anyway. I can't remember anyone complaining about the changes > > introcuded by that concrete issue in the last years as well. > > > > > I > > > haven’t looked at the code myself but is there no way to keep it > > > backward compatible while also keeping the new changes? > > > > In my opinion this is an unnecessary meta-discussion until a concrete > > problem has been described introduced by LOGCXX-319 or other changes. > > So at least I won't reconsider each and every change since the last > > release. > > > > 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 > > > >
Re: [log4cxx] Towards a release
Guten Tag Stephen Webb, am Dienstag, 3. März 2020 um 06:51 schrieben Sie: > As a result of knowing the macros are "blocks", most LOG4CXX_ XXX() code > does not have a trailing semicolon. And that has been unexpacted behaviour in the past and users did wrong, so has been changed. The current implementation seems to be more in line with what users seem to expect and doesn't result in difficult to debug error messages anymore. https://issues.apache.org/jira/browse/LOGCXX-319?focusedCommentId=12670094=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12670094 https://issues.apache.org/jira/browse/LOGCXX-393?focusedCommentId=13201496=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13201496 > I would like to be able to compile my systems with both 0.10 and 0.11 for a > transitional period (i.e. to avoid a 'big bang' switch over). Then you should carefully look at each and every patch applied between those two versions, especially about the many memory- and multi-thread- related problems. Multiple things have changed. https://issues.apache.org/jira/browse/LOGCXX-394 > If I was forced to use a 'big bang' change, I would probably just change to > log4cpp which is already supported by package managers (conan.io and vcpkg). Which is easier of course than to simply add a semicolon using search & replace. :-) When introducing support for CMAKE, it has even been discussed to remove Autotools as well to focus on one build system only. So happy discussing which backwards incompatible changes are allowed and which not... https://github.com/apache/logging-log4cxx/pull/12#issuecomment-580930215 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
Re: [log4cxx] Towards a release
I can describe the concrete problem I will have with LOGCXX-319 given that all the code for which I am responsible has been written using log4cxx 0.10 In 0.10, you have to know the macros are "blocks" not "statements" as any conditional logging macro has to be written without a trailing semicolon. For example: if (someCondition) LOG4CXX_INFO(m_log, "Condition 1 message") // Note a semicolon here will cause a compile error else LOG4CXX_INFO(m_log, "Alternate message) As a result of knowing the macros are "blocks", most LOG4CXX_ XXX() code does not have a trailing semicolon. I would like to be able to compile my systems with both 0.10 and 0.11 for a transitional period (i.e. to avoid a 'big bang' switch over). If I was forced to use a 'big bang' change, I would probably just change to log4cpp which is already supported by package managers (conan.io and vcpkg). I would be surprised if any unix distribution would change to 0.11 log4cxx if its API is incompatible with 0.10. Regards Stephen Webb On Tue, Mar 3, 2020 at 4:28 AM Thorsten Schöning wrote: > Guten Tag Ralph Goers, > am Montag, 2. März 2020 um 16:34 schrieben Sie: > > > There is a difference between a user’s compile failing vs the build > > having changed. > > And which? Things don't work in the worst case either way and need to > be adopted. Why exactly is getting rid of build support by ANT > acceptable for users relying on that, but applying LOGCXX-319 might(!) > not be? > > If I remember correctly, the concrete changes could even be adopted > using automatic search > > > Given how old log4cxx is I would expect it to be > > used in a fair number of places despite its version number. > > And a fair number of users applied either the available patches > already since the last release or simply work with master already > anyway. I can't remember anyone complaining about the changes > introcuded by that concrete issue in the last years as well. > > > I > > haven’t looked at the code myself but is there no way to keep it > > backward compatible while also keeping the new changes? > > In my opinion this is an unnecessary meta-discussion until a concrete > problem has been described introduced by LOGCXX-319 or other changes. > So at least I won't reconsider each and every change since the last > release. > > 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 > >
Re: [log4cxx] Towards a release
It may be helpful to document breaking changes in a clear manner. While the version number may imply instability, the fact that it's been released by a super longtime PMC already brings up the logistical issues of backward compatibility and how one wishes to define that. On Mon, 2 Mar 2020 at 11:28, Thorsten Schöning wrote: > > Guten Tag Ralph Goers, > am Montag, 2. März 2020 um 16:34 schrieben Sie: > > > There is a difference between a user’s compile failing vs the build > > having changed. > > And which? Things don't work in the worst case either way and need to > be adopted. Why exactly is getting rid of build support by ANT > acceptable for users relying on that, but applying LOGCXX-319 might(!) > not be? > > If I remember correctly, the concrete changes could even be adopted > using automatic search > > > Given how old log4cxx is I would expect it to be > > used in a fair number of places despite its version number. > > And a fair number of users applied either the available patches > already since the last release or simply work with master already > anyway. I can't remember anyone complaining about the changes > introcuded by that concrete issue in the last years as well. > > > I > > haven’t looked at the code myself but is there no way to keep it > > backward compatible while also keeping the new changes? > > In my opinion this is an unnecessary meta-discussion until a concrete > problem has been described introduced by LOGCXX-319 or other changes. > So at least I won't reconsider each and every change since the last > release. > > 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 > -- Matt Sicker
Re: [log4cxx] Towards a release
Guten Tag Ralph Goers, am Montag, 2. März 2020 um 16:34 schrieben Sie: > There is a difference between a user’s compile failing vs the build > having changed. And which? Things don't work in the worst case either way and need to be adopted. Why exactly is getting rid of build support by ANT acceptable for users relying on that, but applying LOGCXX-319 might(!) not be? If I remember correctly, the concrete changes could even be adopted using automatic search > Given how old log4cxx is I would expect it to be > used in a fair number of places despite its version number. And a fair number of users applied either the available patches already since the last release or simply work with master already anyway. I can't remember anyone complaining about the changes introcuded by that concrete issue in the last years as well. > I > haven’t looked at the code myself but is there no way to keep it > backward compatible while also keeping the new changes? In my opinion this is an unnecessary meta-discussion until a concrete problem has been described introduced by LOGCXX-319 or other changes. So at least I won't reconsider each and every change since the last release. 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
Re: [log4cxx] Towards a release
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 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 > >
Re: [log4cxx] Towards a release
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
Re: [log4cxx] Towards a release
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. On Mon, Mar 2, 2020, 9:32 PM Thorsten Schöning wrote: > Guten Tag Stephen Webb, > am Montag, 2. März 2020 um 11:05 schrieben Sie: > > > In my review I did encounter an item of concern to me. I see that 0.11 > > cannot be used in place of 0.10 due to LOG4CXX-319. I personally am > > responsible for hundreds of thousands of lines of code that will not work > > with this change. > > What's the exact problem? I suggest reopneing the issue and discussing > details there. That change even worked for a pretty old, non-standard > Borland compiler I was using back then. > > > https://issues.apache.org/jira/projects/LOGCXX/issues/LOGCXX-319?filter=allissues > > 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 > >
Re: [log4cxx] Towards a release
Guten Tag Stephen Webb, am Montag, 2. März 2020 um 11:05 schrieben Sie: > In my review I did encounter an item of concern to me. I see that 0.11 > cannot be used in place of 0.10 due to LOG4CXX-319. I personally am > responsible for hundreds of thousands of lines of code that will not work > with this change. What's the exact problem? I suggest reopneing the issue and discussing details there. That change even worked for a pretty old, non-standard Borland compiler I was using back then. https://issues.apache.org/jira/projects/LOGCXX/issues/LOGCXX-319?filter=allissues 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
Re: [log4cxx] Towards a release
I have not changed anything. Just used 'mvn post-site'. It is simply an attempt to see if there is anyone interested in log4cxx. In my review I did encounter an item of concern to me. I see that 0.11 cannot be used in place of 0.10 due to LOG4CXX-319. I personally am responsible for hundreds of thousands of lines of code that will not work with this change. I would suggest we need a configure option to use the 0.10 macros instead of the new ones. The new macros can be the default. Regards Stephen Webb On Mon, Mar 2, 2020, 7:50 PM Thorsten Schöning wrote: > Guten Tag Stephen Webb, > am Sonntag, 1. März 2020 um 07:19 schrieben Sie: > > > I have posted the result of "mvn post-site" to > > https://stephen-webb.github.io/ > > Looks the same like what is published already to me: > > https://logging.apache.org/log4cxx/next_stable/index.html > > Shouldn't it be more of interest to review what you have changed to > get that result instead of the result itself? Did you replace more ANT > with MVN or ...? > > 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 > >
Re: [log4cxx] Towards a release
Guten Tag Stephen Webb, am Sonntag, 1. März 2020 um 07:19 schrieben Sie: > I have posted the result of "mvn post-site" to > https://stephen-webb.github.io/ Looks the same like what is published already to me: https://logging.apache.org/log4cxx/next_stable/index.html Shouldn't it be more of interest to review what you have changed to get that result instead of the result itself? Did you replace more ANT with MVN or ...? 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
