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

[Michael Van Canneyt]

On Thu, 16 Apr 2026, Tomas Hajny via fpc-devel wrote:

> On 2026-04-15 18:24, Michael Van Canneyt via fpc-devel wrote:
>> On Wed, 15 Apr 2026, Tomas Hajny via fpc-devel wrote:
>>> On 2026-04-15 17:53, Michael Van Canneyt via fpc-devel wrote:
>>>> On Wed, 15 Apr 2026, Tomas Hajny via fpc-devel wrote:
>>>>> On 2026-04-15 15:18, Graeme Geldenhuys via fpc-devel wrote:
>>> 
>>> .
>>> .
>>>>>>   * Automation for the fpc/build repository: when fpcsrc is tagged
>>>>>>     with a release or RC tag, a GitLab CI pipeline automatically
>>>>>>     pins the submodule pointers in fpc/build and applies the same
>>>>>>     tag there, eliminating the manual submodule update step.
>>>>> 
>>>>> Please, read the discussion (especially our communication with Martin 
>>>>> F.) to get better understanding why this particular part doesn't fit the 
>>>>> needs. I don't say that nothing might ever change in this area compared 
>>>>> to the current state, but please note that cross-building is _not_ 
>>>>> applicable for all FPC supported targets and thus building for all 
>>>>> targets cannot be tested / checked by a single person or anything like 
>>>>> that - which is why testing the release build against once created tag 
>>>>> is not enough.
>>>> 
>>>> No, but we definitely can automate it for the major platforms.
>>> .
>>> .
>>> 
>>> Please, note what kind of "automation" is mentioned above
>> 
>> I did, and I followed the discussion. I don't see the problem at all.
>> 
>> Maybe you can explain it as you seem to understand it ?
>
> 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.

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.

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

Michael.