[fpc-devel] [RFC] Modernising the FPC Release Process -- A Question

[robert rozee]

Sent: Saturday, April 18, 2026 at 1:30 AM
From: "Graeme Geldenhuys via fpc-devel" <fpc-devel at lists.freepascal.org>
>
> Unfortunately, the FPC project seems to have stalled since the migration
>

i'd like to look at this from a different direction by exploring a question:

assumption:
-----------
FPC 3.2.2 has been around, unchanged, for 4 or 5 years. in that time it is fair
to say that pretty much all of the bugs in 3.2.2 have been discovered and, in
one way or another, documented. admittedly, some of that 'documentation' is in
the form of patches that currently sit in limbo. but, nonetheless, a record
exists.

observation:
------------
i've been using FPC 3.2.2 for much of the duration that this specific version
has existed, and where needsbe i have managed to avoid, work around, or develop
my own patches for bugs that affect ME. notably for me was my patch to fix the
incorrect handling of GLIBC symbol versions (erroneously assigning the newest
symbol version discoverable on the build machine to code that was written
against much earlier prototypes). but most importantly - i have been able to
make FPC 3.2.2 work, for me, just fine; i have never found FPC 3.2.2 to be
lacking.

question:
---------
why on earth would anyone want to use any build of FPC other than 3.2.2? for
the vast majority of users it works fine. ok, not so great for apple users, but
then they are off on their own little journey with FPC 3.2.4, and i wish them
the  very best of luck in their endeavors.

has anyone ever found themselves in a position where it has NOT been possible
for them to create and compile a program to solve any specific problem using
FPC 3.2.2? ie, are there classes of computational problem for which FPC3.2.2 is
incapable of being used to find a solution?

suggestion:
-----------
why not ask Claude to create a treatise detailing all the BUGS that it can
identify through examining the source code differences between FPC 3.2.2 and
the 4/5 years of subsequent code changes on GitLab? this would provide a
blueprint of fixes that could be applied to create a short-term successor to
the HIGHLY successful FPC 3.2.2. or it could be used as an errata document
to warn users of 'things to avoid'.

one could also ask Claude to create a second treatise, detailing all the new
FEATURES that have been added since FPC 3.2.2. this would then provide a
blueprint to what enhancements could be considered for any future FPC 4.

with Claude doing the majority of the work (and writing NO code) the main thing
required to create these treatises would be a financial contribution from the
FPC Foundation to fund Claude's efforts. NO DEVELOPER INPUT REQUIRED.


could this be a way forward that no one would object to?


cheers,
rob   :-)