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

[Michael Van Canneyt]

On Wed, 15 Apr 2026, Tomas Hajny via fpc-devel wrote:

> On 2026-04-15 15:18, Graeme Geldenhuys via fpc-devel wrote:
>
>
> Hi Graeme,
>
> First of all - I understand that you try to move things forward and I 
> appreciate your interest. In addition, I understand that you prefer start 
> working on something than participating in potentially endless discussions. 
> However, I believe that you should read at least some parts of that 
> discussion. One of those parts is the question (very correctly raised by 
> Marco!) how does having a fixed schedule ensure that the fixed releases 
> contain considerable advances against each other while still ensuring 
> reasonable quality / stability for patch releases. Please, see below for 
> other two comments.
>
> Regarding the number of merge requests - have you tried comparing the amount 
> of changes waiting in the merge requests to the amount of changes pushed to 
> the repository within the last 5 years? I didn't try to compare it myself, 
> thus I don't know the answer, but I believe that such a comparison might be 
> beneficial in order to find out whether the waiting merge requests (some of 
> them probably useful, some other possibly bad and not appropriate for merging 
> in any case) are substantial part of the problem, or whether there are other 
> possibly much more important obstacles.
>
>
>> A few weeks ago I raised concerns about the 130+ open merge requests
>> sitting unactioned in the GitLab instance. That thread drew a lot of
>> responses, and it was clear the frustration is widely shared. What it
>> did not produce was a concrete path forward.
> .
> .
>>   * 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.

The smaller platforms can tag along at their own rythm.

I really don't think that the small platforms are where our biggest user base is.
At least with the proposal of Graeme, we'll be helping the majority of our users.

Will it be perfect ? No. But no release ever was. 
At least with regular releases there will be *some* progress. Now there is none.

It is possible for countless open source projects. 
There is nothing special about FPC that would prevent us from doing the same.

We can of course discuss possible pitfalls till judgment day comes, 
but this does not help our users.

Michael.