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?
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.
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.
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.
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.
Of course, these are the words of a spectator who is not in a position to dictate anything.
There is a release process:
https://www.fltk.org/cmp.php#RELEASE
In the old CMP, the requirement was to absolutely solve all High and Critical bugs
before release. All moderate/low/RFEs that can't be solved by release would be bumped
to the next release for resolution.
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.
And we've since moved to github issues for managing bugs.
The STR's are there as a history, and to finish still-open issues/bugs/RFEs.
There's currently 112 STRs against 1.3 (0 critical, 0 high, 25 moderate, 26 low, 61 RFE's)
There's currently 189 STRs against 1.4 (0 critical, 17 high, 22 moderate, 29 low, 121 RFE's)
In github there's 60 open issues, I don't think we have a rating system for those, [ . . . ]
Yes, most of what you say is true; some items I thought I'd comment about:
There is no established standard of what it takes for a new release.
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.Oh, but they are a big deal.. keeping the docs synced with the changes is
pretty big, and this time there's been many.
Changing svn -> git, configure -> cmake, combined with the broach changes
under the hood from Apple, Linux (X11 -> Wayland), and Windows, it's been
a bit tough to keep up.
We need to clean up all those README files; consolidate and remove,
probably rewrite many of them.In that spirit, I would encourage the team to consider moving to time-based releases -- say once per year, or perhaps every six months.
That'd be good for the maintenance releases, no question.
We're in a tough position having to freeze 1.3 (which keeps getting unfrozen, lol) to
prevent fork issues, focusing on 1.4, but due to the above mentioned issues, it's
been tough to get 1.4.0 out in what we'd prefer to be a reliable state. But we should
probably push on it harder.
Of course, these are the words of a spectator who is not in a position to dictate anything.They're good ideas, just been hard to manifest due to "too much to do/spread too thin"
I think.
I'm sure Albrecht will weigh in too. He's been busy I know on lots of bugs/issues.
I've been using 1.4 myself in production, keeping up with the current state of development
to carefully pick and choose the commits that make sense, and internally freeze, applying
only fixes to my internal production release, and releasing static binaries, so as not to require
shared .so's from linux distros to run binaries.
I advise other developers of active FLTK apps to do the same.