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.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
