Since there's no central repository of C++ libraries (or C, or several other languages for that matter; Rust providing one is a nice change of pace), it'll be fairly difficult to get real usage stats about what minimum compiler versions and such are still in use out there. Now I know it's not the "oldest" thing out there, but I typically defer to whatever is in Debian Stable (and maybe even RHEL sometimes, but they're super ancient) for an idea of what's a safe baseline. In this case, I see https://packages.debian.org/buster/liblog4cxx10v5 which is using a fairly old libstdc++6 (>= 5.2) whereas Buster seems to package a much more recent version (8.x).
On Sun, 23 Aug 2020 at 07:01, Thorsten Schöning <tschoen...@am-soft.de> wrote: > > Guten Tag Robert Middleton, > am Sonntag, 23. August 2020 um 03:31 schrieben Sie: > > > I'm working on changes for log4cxx at the moment that involve upgrades to > > use C++11 features; that would definitely require a major change in the > > versioning, although the API would be largely the same. > > OTOH, the work on smart pointers you did in the past changed the API > as well. Those things are pretty easy with having a "0.x" from almost > every point of view. > > So in my opinion, creating a versioning scheme to distinguish two > different versions from each other is fine. Switching to 1.0 only > because X time has past is not. I'm using other projects as well in > production keeping 0.x versions and don't care too much. > > > Part of the question with that as well is what platforms and > > compilers are supported, as Thorsten uses a very old compiler. > > In the worst case, I'm simply forking and using the old code base for > my needs until I get the resources to upgrade my projects. Need to do > that anyway at some point, just didn't have the resources yet. > > > So would it make sense to have two branches for development, the > > "legacy" 0.XX version and a new 1.XX version that depends on (at > > least) C++11? > > Seems pretty uncommon to me to actively develop/maintain a 0.x and a > 1.x, doesn't it? So maybe prefer a 0.x -> 1.x -> 2.x and maintain 1.x > and 2.x only? OTOH, 2.x might make people believe in compatibility > with log4j2 too much? > > Let's explicitly ask on the list if any legacy version supporting old > compilers is if interest at all? > > I might be the only one, in which case it's not worth taking care too > much at all. I'm fine with what 0.x provides currently and am not sure > if I would enhance that version at all if I needed to, in favour of > upgrading to 1.x first and enhancing afterwards. Legacy always is a > dead-end after all. > > 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>
