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

[Nikolay Nikolov]

On 4/17/26 5:10 PM, Michael Van Canneyt via fpc-devel wrote:
>
>
> On Fri, 17 Apr 2026, Nikolay Nikolov via fpc-devel wrote:
>
>>
>> On 4/17/26 4:32 PM, Graeme Geldenhuys via fpc-devel wrote:
>>> On 2026-04-17 13:00, Marco van de Voort via fpc-devel wrote:
>>>> And then we still have to find out if that concept works at all in 
>>>> the FPC context.
>>>
>>> And yet it works flawlessly on 10,000s of other open source projects 
>>> (big and small). I simply don't know why you think FPC is so special 
>>> that it will not work here.
>>
>> FPC is special in the regard that it is a compiler and that it has an 
>> extremely high coupling between compiler and rtl units. So, changes 
>> are very interdependent. It's hard to separate them and treat them as 
>> independent, because they're simply not.
>
> So ? How is the proposed flow at odds with this ?
>
> I would think rather the opposite: by doing a MR you ensure related 
> commits remain together.

I'm not sure I understand the question. Graeme's proposal includes 
squashing commits. Squashing rewrites history and converts many commits 
into one. Currently, the "eliminate_global_state" branch contains 1080 
commits. All of these will be merged into one. Then, if it turns out 
this breaks some obscure platform in a weird way, we'll have an "all or 
nothing" approach - revert everything, or keep it broken. You won't have 
any idea which of these 1080 fine grained commits really caused this bug.

Or, are you talking about something else?

The problem with git is that there are so many workflows possible and 
that no two developers can agree which subset of it to use.

Nikolay