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

[mailinglists at geldenhuys.co.uk]

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 -