| |
| |
On 7/24/21 11:42 PM Rob McDonald wrote:
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.
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. ... Not
wanting to leave legacy users out of the newest features leads
to supporting them forever.
This was not meant to define a strategy for the future. It does only
describe the current situation.
There's another reason to do it this way: if we ever need to
backport changes from the next gen FLTK (4.0) and create a new
release this would be *much* easier for 1.4.x than for 1.3.x
because of the big structural code base changes. This is also a
pragmatic solution based on the current situation rather than a
future strategy.
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.
Exactly. (But I would say "also for the sake of legacy systems"
because it doesn't cost anything)
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.
We're probably not able to use this "testing everything we support"
strategy. Even with docker you can only test Linux platforms on
Linux (unless I'm missing something). I don't know what the CI
providers exactly do for using Windows and macOS (maybe VM's?). And
using the free CI tools as we do does only help to find some build
issues. We can never test each build config and we can't test live
GUI programs.
This is why I think we need to define software and build system
requirements rather than specific system versions. Maybe there can
be a mixture of both, but this needs to be discussed anyway (but not
yet).
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.
Good point. I've also thought about using a regular release cycle in
the future. This might be possible if we're only doing updates with
some new features and bug fixes. The move from 1.3 to 1.4 with all
that driver stuff and new build system (CMake) was a much bigger
change. Such a change would maybe require an out of order release
anyway.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/396771a0-74e6-0d73-bf5e-28ba7cd81b06%40online.de.
[ Direct Link to Message ] | |
|
| |
