On Wednesday, October 20, 2021 at 2:46:25 AM UTC-7 Ian MacArthur wrote:
On Saturday, 16 October 2021 at 09:34:41 UTC+1 rempasch wrote:
I'm just wondering if there is a specific plan for what needs to been done in order to hit the release or if it will be done when the developers decide that what has been implemented is enough. Any ideas?
Not as such - we don't have sufficient capacity to make that plan.
I think it is very much in the realm of "when it's done, it's done" I'm afraid.
I've lurked around the fringes of FLTK development long enough to understand the realities of the process. Apologies if my observations offend anyone. I am most grateful to the developers for all their work producing FLTK.
FLTK does not have a central driving authority mandating features or setting schedules. There is no established standard of what it takes for a new release.
The
STR System provides some level of bug tracking and TODO list management that comes into play when a release nears. Between releases, it mostly acts as an accumulator.
The developers have a strong commitment to backwards compatibility, fixing bugs, and keeping FLTK up with new OS releases and API changes from the surrounding world.
New feature development is driven by developer interest and needs.
Eventually, one of the developers gets motivated to produce a release, starts making noise, gets a few other developers on board. Someone triages the STR's into a release list and a few devs work to whittle down the list. Some concentrated effort follows and a release is eventually produced.
Sometimes the time between releases can become quite extended. During these times, the developers fall into the habit of using development versions in their own applications (and eventually recommending that to users who would otherwise use an 'official' release). Eventually the released version becomes increasingly irrelevant.
Along with this, most package management systems are hesitant to pick up unofficial releases.
Since there is no rigorous standard for what it takes to justify a new release, I would encourage the FLTK developers to pursue smaller and more frequent releases. They don't have to be a huge deal if we don't make them a huge deal.
In that spirit, I would encourage the team to consider moving to time-based releases -- say once per year, or perhaps every six months.
The hope would be that smaller incremental releases would be less burdensome come release time while enabling users and package managers to better stay up to date with what the developers are developing and using.
Of course, these are the words of a spectator who is not in a position to dictate anything.
I am exceedingly grateful that FLTK has survived so long. My application has roots back to Iris GL and the FORMS library, made the transition to X-FORMS and OpenGL, and then eventually to FLTK. I am sure the list of GUI Widget libraries that have a development lineage back to the early 1990's is very short. If FLTK were to be abandoned, it could well be catastrophic for my application. With this in mind, the slow and steady plod may well be the best way -- two past more ambitious efforts v2.0 and v3.0 have since been abandonded.
Rob