On 2026-04-15 23:09, Tomas Hajny via fpc-devel wrote:
If I understand it correctly, this part of the proposal suggests replacing the current mechanism of keeping fpcbuild repository up to date
Hi Tomas, The intent was never to replace the current mechanism of keeping fpc/build continuously up to date. Whatever process the team uses today to keep submodule pointers current during active development should remain exactly as it is. The CI automation described in the proposal is an *additional* step that fires only at the specific moment a release or RC tag is pushed to fpcsrc. At that point, and only at that point, it pins the fpc/build submodule pointer to the exact tagged commit so that the release build is reproducible and auditable. To put it plainly: normal development workflow in fpc/build continues unchanged. The automation handles one narrow, currently manual [I assume] step — "now that we have tagged fpcsrc, update fpc/build to record exactly which commit that tag corresponds to." Nothing more than that. I also want to clarify the intended scope. The proposal was not suggesting that CI automation could build and verify every platform FPC supports — that is clearly not feasible given the breadth of targets. The automation was scoped to a Tier 1 set of platforms that cover the majority of the FPC user base: Linux, Windows, and macOS on the common architectures. Niche and cross-compiled targets would still rely on the people who own those platforms, exactly as they do today. I agree with you that the proposal should spell this out explicitly rather than leaving it to interpretation. I will update the document to make both points clear: that the automation is additive and not a replacement for continuous development updates, and that its CI scope is limited to a defined Tier 1 platform list. Regards, - Graeme - _______________________________________________ fpc-devel maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
