In my experience, projects that rely on extremely limited
toolchains aren't in a big hurry to update to the latest
release of every dependency. They are generally happy to
remain frozen in time with a well tested system that works.
What is the union of esoteric systems stuck on ancient
toolchains that also need to update to the latest / greatest
FLTK?
Hmm, to clarify: did you mean intersection rather
than union? That would likely be a very small set.
Good catch -- I did mean intersection rather than union. I agree it is a very small set -- and one that is probably only identifiable by the developers in that situation.
As FLTK moves from 1.3.X to 1.4.X, it is the perfect time
to draw some line in the sand. To determine what will be
supported (and hopefully tested) - and what will be allowed to
remain at 1.3.X (or earlier).
I believe that FLTK 1.4 should stay as compatible to 1.3 as possible
(regarding API and build system) because 1.4 is long
(over?)due and we added so many improvements (and fixes) which are
not in 1.3 that we should offer a real / simple migration path from
1.3 to 1.4 for as many platforms as possible.
But I do also think that we need to move forward. See below.
I think you are perhaps a little too conservative here. This argument - that the release process has lagged the magnitude of development is not a great reason. As a volunteer driven effort, FLTK's development pace is likely going to always be somewhat slow and deliberate (not a bad thing). Not wanting to leave legacy users out of the newest features leads to supporting them forever.
Once again I wonder if the systems we're worried about are even considering updating to 1.4. If they are happy with 1.1 or 1.3, do we really expect them to jump forward.
On the other hand, since we all desire a 1.4.0 release ASAP, there isn't much point in opening up the development rules for 1.4. 1.4 should probably ship with the current rules -- not for the sake of legacy systems -- but in the interest of getting it out the door ASAP.
My thoughts on future FLTK development (short term and mid/long
term, certainly incomplete):
- keep FLTK 1.4 as-is, don't change software requirements (see the
"pragmatic answer" above)
- change build requirements only as much as absolutely necessary
(e.g. we removed bundled IDE's)
- stay conservative with CMake minimum version (we moved from 2.6.3
to 3.2.3)
- release FLTK 1.4 "soon" (soon means hopefully this year)
The next version after 1.4 could be a major step with a new major
version number. This would be 4.0 because 2.0 and 3.0 have already
been burnt (without releases). This next major version would allow
us to change build requirements and maybe also supported systems.
Some ideas:
- allow FLTK to use <some> C++11 features internally, i.e.
require a C++11 compiler ('auto' comes to mind [4])
- allow namespaces (particularly anonymous namespace)
- allow select STL features like std::vector< some-types >
- drop autoconf build for easier maintenance (see also STR #2916 [3]
from Jan 2014)
- update the CMP accordingly (this would probably be the first step)
- keep the API backwards compatible as much as possible (as we
always did)
This way we could modernize the FLTK code base and those users with
older compilers/build systems could stay with a "more modern" FLTK
1.4 from 2021 rather than a less maintained FLTK 1.3 (macOS support
+ some bug fixes since 1.3.4 (Nov 2016)).
Thoughts about very restricted platforms like embedded systems that
use FLTK: I believe that those platforms use cross compilers anyway.
If they are stuck with really old cross tools then they are
(probably already) also stuck with old FLTK versions. I suspect that
some of these platforms use 1.1 anyway because they don't have
working UTF-8 support - unless they are using ASCII only. That said,
if these platforms can use FLTK 1.4 at all this should be a
sufficient base for the next 5 years or so. After that time a switch
to FLTK 4.0 (released in 2022 and later) would involve new, more
modern cross tools anyway. Even the ancient build systems used for
cross compiling those old embedded systems might fade away over time
because the hardware may die (unless they're using well maintained
VM's).
Does this sound like a more encouraging plan?
I am not a core FLTK developer, so I can't really speak to the value or difficulty of each specific policy change.
I think the most important step is updating the CMP. While there is a ton of great information in there, I think it needs to define what systems are supported. That will likely be done in terms of platform and toolchain version numbers. It would be best to actually have CI testing of everything on that list -- as mentioned, Docker could be a great help here.
Once there is a clear handle on what is supported, there can be a roadmap that updates the support basis as new versions are developed and released.
This may imply that FLTK should try to pursue a regular cadence of time-based releases -- most linux distributions and developer tools have gone to time-based releases, it might be good to pseudo-align FLTK's targets and goals with those schedules. I'm not thinking direct alignment, but instead lagged alignment -- for example, FLTK aims to support official versions released over the past five years of Ubuntu, gcc, clang, msvc, CMake, MacOS, Windows... That five year window moves forward, but in spirit it remains the same.
Rob