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 <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&replace. > > > 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 <boa...@gmail.com>
