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

[Nikolay Nikolov]

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. This doesn't apply to most of 
the packages. That's why there's extra effort on keeping the compiler's 
history linear, avoiding merge commits and running regular automated 
tests on many platforms, so that bugs are caught early and so that it is 
easy to find the single commit that caused a bug via "git bisect". I've 
worked commercially in my last job on a compiler for a specialized 
language, called "Noir" that used a "squash" all merge request policy 
and it didn't work well with regards to stability and ease of resolving 
merge conflicts. But it was a "move fast and break things" kind of 
startup mentality, so they didn't care much about stability at this stage.

Nikolay