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.
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
