[fpc-devel] [RFC] Modernising the FPC Release Process -- Proposal for Review

Martin Frb lazarus at mfriebe.de
Wed Apr 15 17:44:50 CEST 2026


On 15/04/2026 15:18, Graeme Geldenhuys via fpc-devel wrote:
>
> The central idea is a "Release Train" model: releases depart on a
> fixed schedule regardless of which features are ready, removing the
> "just one more thing" pressure that has kept us in freeze. The
> document covers:

While (as outsider) I would welcome a "time"-ish based cycle, I don't 
think it will work entirely.

You mention it works for the kernel. But the kernel does not have 
regression forced by other products. (well, hardware can change, but 
that is more new hardware to support gets added / hardware already 
supported does not suddenly stop).

FPC needs to run on several OS => if MS did make changes and distributed 
them via its update, and FPC would no longer work, then that should get 
fixed. Rolling out on exact time, makes no sense then. Yes sure the fix 
might come in 6 month then. But if it could be there in less time...

But more troubling than the wait, would be the "which version works with 
which OS" => As for the core list of OS (the big 3 afaik) every released 
version should work at the time of release.
That rule should IMHO not be broken. Or only, if the team no longer has 
a person that can fix it.


That rule shouldn't cause to big delays **if** all else works.

Yes, currently - afaik - its waiting for some MacOS fix => which 
apparently exists? So not sure what takes the time => but it seems to be 
more in "all else" than the "wait for the OS".

If the "all else" isn't working, then having a timestamp to act on wont 
fix it. Hence, I thing the "wait for the big 3" should not be a problem.


More information about the fpc-devel mailing list