Is there a roadmap for the 1.4 release?

[Charalampos Rempas]

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?

[Ian MacArthur]

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.

[Rob McDonald]

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

 

[Albrecht Schlosser]

On 10/21/21 8:15 PM Rob McDonald wrote:

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.

+1

Such a time-based release is something I've been considering too. I believe that we could switch to such a scheme once FLTK 1.4.0 has been released.

And -- without any guarantees -- my *hope* is that we can release 1.4.0 at the beginning of 2022.

[Greg Ercolano]

On 10/21/21 11:15 AM, Rob McDonald wrote:

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.

    Yes, most of what you say is true; some items I thought I'd comment about:

FLTK does not have a central driving authority mandating features or setting schedules.

    Actually Albrecht is our software manager.

    For just over a decade it used to be Mike Sweet, who got busy working at Apple
    on CUPS and had to disconnect from FLTK back in 2013 or so where I took over the
    website management, and around that time Albrecht became the manager.

There is no established standard of what it takes for a new release.

    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.

    Now that we've switched to github, I think we have yet to iron out the criteria for releases,
    perhaps keeping the old CRITICAL/HIGH/MED/LOW/RFE labels and classifying all open issues
    accordingly, pre-release.

    I believe Albrecht has some ideas on this, not sure if they've been documented as yet,
    but we definitely need to document the new release process for github issues before
    we can even begin the release steps.

    I think mostly attention has been on solving key 1.4 issues and stabilizing.

    We also haven't had a minor release bump in a very long time (1.1 -> 1.3 was the last one I think,
    which was a long time ago) , and there's a lot in development right now, esp to keep up with Apple's
    recent changes that Manolo's been busy with, and with the switch to cmake, so we've kept extending
    1.4 release to wait for things to settle.

    In Linus's tradition, "release early, release often", FLTK has taken the opposite approach.
    In truth releasing often takes a lot of effort, and while Linux has a lot of devs, we do not,
    and we've all been spread thin I think by recent events, and the switch to git/github.

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, so much as
    subject tags ("cmake", "bug", "documenation", etc) which have to be applied manually by devs
    currently. And usually once labels are assigned, the issue usually starts moving quickly to being
    solved and closed.

Eventually, one of the developers gets motivated to produce a release, starts making noise, gets a few other developers on board.

    Heh, that'd usually be Matt, who has since become busy with his family business and so not as much available.
    It's true one of us needs to take up the task stick and start wielding it. It was easier I think too when there were
    more devs.

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.

    Typically the open bugs get accumulated then get assigned to devs to focus on
    solving them.

    Unassigned issues are forced to be assigned to 'someone', or get bumped to the
    next 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.

[duncan]

    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, [ . . . ]

In theory, there's nothing to stop a determined "user" who is expert in a particular area

helping with the open STRs and github issues and supply patches or pull requests, but

in reality many of the 17 "high" STRs require some serious knowledge of the internals

of FLTK and/or the subtleties of working across different platforms and compilers with

specific third-party libraries, Unicode and Internationalization.

But that's why people are using FLTK: to hide those internals for cross-platform tools.

Personally, I have no desire to learn about the internals of X11, Windows or MacOSX.

So if you aren't working on these things anyway as part of your day job, there's a lot to learn!

I've looked but here really aren't many "low hanging fruit" that can be picked off the STR list :-(

[Rob McDonald]

On Thursday, October 21, 2021 at 2:37:29 PM UTC-7 erco wrote:

    Yes, most of what you say is true; some items I thought I'd comment about:

Thanks for your thoughtful reply -- and for all the FLTK work you do. 

Your answers are far more rigorous than mine.

 

There is no established standard of what it takes for a new release.

    There is a release process:
    https://www.fltk.org/cmp.php#RELEASE

I did not mean there was not a release process -- or even guidelines on quality for a release.

I really meant that there was not an established threshold for how many changes need to accumulate before a new release would be pursued.  It happens when it happens.

Theoretically, ten years of changes could accumulate in a development branch without anyone pursuing an official release.  Unlikely, but there is no set threshold.

That said, significant effort is expended to maintain API compatibility across minor versions (1.1 to 1.3 to 1.4).  And ABI compatibility is maintained across patch versions (1.3.0 to 1.3.5).  So, by implication, any ABI breaking change will force a minor version increment.  I believe the abandoned proposals for 2.0 and 3.0 were API breaking, so a similar rule would be derived there.

<Snipped a bunch of wise and obviously correct input from Greg> 

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.

I think this all goes together.

The more stuff that accumulates, the harder it is to sweep it all together into a release.  Maintenance releases (last number incremented) should be 'easy'.

A lot of big things got pushed from 1.3 to 1.4 and now 1.4 represents a lot of changes -- not just in code, but as you point out, process changes like git and cmake have long tails of effect on documentation, etc.

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.

I recently made this jump myself -- but I don't feel good about it.

Here is a proposed guideline for triggering a new release...

When an unreleased version identified by a Git SHA is recommended over an official release, it is time to start working on a release.

Rob