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

[Marco van de Voort]

Op 6-4-2026 om 23:43 schreef Graeme Geldenhuys via fpc-devel:
>>
>> 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.

Respectfully, I disagree. Time-based releases don't solve anything in 
the current FPC context.

It works for a few large and heavily sponsored projects with heaps of 
grunts that continuously do release engineering work anyway for their 
corporate masters' internal trees. Then you only have to pick a moment, 
and that might as well be on a clock, or by lobbing an arrow at a dart 
board.

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

But not necessarily in fixes. And this up to date bringing of fixes is 
one of the bottlenecks, together with primary reason, the migration to 
GIT. (*)

As said the prerequisites for time based releases are not furfullled by 
FPC, where very little release related action happens outside release 
periods when releases are being prepared outside of my bulk merging of 
non compiler revs.

Having time based releases would only have delivered 
years/(frequency_per_year ) carbon copies of essentially 3.2.2. 
Specially compiler bugs are hardly merged outside of release preparation 
periods. (say a dozen out of 6000 compiler related revs difference 
between main and fixes. Not all will be relevant in 3.2.x context, but a 
dozen is very low bar)

Yes, some build automation _could_help save some minor time, but this 
doesn't yield any speed up in the current release process, because the 
problems are in the actual content creation for the 3.2.x branch. Not in 
the automatized building.

The actual release building phase is usually only one week (one or two 
weekends) for a minor release.

(*) We still have to see if the improvised merge tracking can also be 
easily used for tracking between fixes and release branches. Things that 
used to be simple are now manual and complex with GIT. Florian already 
mentioned the submodule problems.