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