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

[Tomas Hajny]

On 2026-04-16 10:38, Michael Van Canneyt via fpc-devel wrote:
> On Thu, 16 Apr 2026, 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 (i.e. keeping the latest versions of the submodules always 
>> available in the fpcbuild repository) with one time synchronization 
>> only when a particular tag is applied to fpcbuild. That would mean 
>> that building the most up to date version for individual targets could 
>> not be tested before applying the tag (and that testing it again after 
>> any applied fixes would always need manual synchronization). And that 
>> would not be a good idea at all as far as I can tell...
> 
> 1. How is this different from today ?
> 
>    You will always need a manual action to 'fix' the version on the 3 
> repos involved.
>    Whether that is setting a tag or changing the module branch on the 
> .submodules file,
>    it remains an action that needs to be done.

Today's action for getting all needed sources is "git pull 
--recurse-submodules" in a git clone/checkout for the particular branch.


> 2. What stops people from testing using fpcbuild and whatnot without a 
> tag being set ?
> 
>    Nothing. The branch from which the release is being built is known 
> long
>    before any tag is set, so nothing stops people from testing that 
> branch.
>    To test, you need 3 SHAs:  fpcbuild, source and docs. That's it.
>    We put this in a build_id_card.txt or whatever which you can modify 
> and you're all set
>    to launch any build you desire.

My only suggestion was to prevent a step which seemed to make testing 
the builds more complicated. You miss my point that "3 SHAs" are a 
moving target during the release building testing.


> Honestly, I don't understand all the negativity. If there is a problem, 
> we'll fix it.

All the negativity? I only tried to point out specific weak points of 
the proposal. I left major parts without any comments (except a general 
statement that I appreciate Graeme's interest in moving things forward, 
which shouldn't be considered negative hopefully ;-) ). I tried to 
contribute based on my specific experience. I believe that Graeme 
understood it that way, BTW.

Tomas