[fpc-devel] 134 open merge requests - is that normal?

mailinglists at geldenhuys.co.uk mailinglists at geldenhuys.co.uk
Mon Apr 6 23:43:55 CEST 2026


On 2026-04-06 13:42, Kostas Michalopoulos via fpc-devel wrote:
> 
> It also leads to a more buggy compiler though. FPC has great
> stability and i think not making a release until the compiler
> is stable enough is a good thing for end users.

Respectfully, I disagree that time-based releases inherently lead to 
more bugs. In fact, the current 5-year gap since the 3.2.2 release is 
causing a different kind of "instability" for framework developers and 
end-users.

When the "main" branch hoards fixes, features, and updated OS APIs 
(Windows unit, BaseUnix, fcl-passrc, macOS improvements) for half a 
decade, it puts external developers in an impossible position. We cannot 
reasonably ask our users to switch to an in-development branch for 
production work, yet staying on a 5-year-old "stable" release means we 
are forced to maintain a mountain of internal workarounds for bugs that 
have long since been fixed in FPC's repository.

The Benefits of Time-Based Releases (as seen in OpenJDK, LLVM, etc.):

* Predictability: Framework authors can plan their roadmaps knowing 
exactly when they can deprecate old workarounds.

* Reduced "Fixes" Overhead: With a 6-month cycle, the need for complex 
backporting to "fixes" branches diminishes. If a feature misses a 
window, it's only 6 months away, not 5+ years.

* Better Feedback Loop: More frequent releases mean more users testing 
the "new" code in real-world scenarios sooner, rather than a massive 
"big bang" release that is guaranteed to have regressions due to the 
sheer volume of 5 years of accumulated changes.

* Automation over Manual Labour: The "man-power" argument is real, but 
the solution is to automate the release engineering process (CI/CD, 
test-suite validation) so that a release becomes a "non-event" rather 
than a heroic manual effort.

Kostas, you mentioned you use the main branch daily and have commit 
access. That is a luxury many of our users don't have. For those of us 
trying to build an ecosystem on top of FPC, the lack of a formal release 
makes the compiler feel stagnant to the outside world, even if the 
repository is active.

I am more than happy to contribute missing APIs for the Windows unit or 
fix broken constants I discovered in BaseUnix, but having to wait 5+ 
years before other developers can benefit from those contributions is 
simply not right. It doesn't take a genius to recognize that five years 
is an eternity in software development.

We don't need every release to be a "major" milestone. We just need the 
"stable" baseline to move forward at a pace that matches the modern 
development landscape. If we don't address this, we risk fragmenting the 
community further.

Regards,
   Graeme


More information about the fpc-devel mailing list