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

[Michael Van Canneyt]

On Wed, 15 Apr 2026, Marco van de Voort via fpc-devel wrote:

>
> Op 15-4-2026 om 21:29 schreef Michael Van Canneyt via fpc-devel:
>>
>>
>> No worries there:
>>
>> I already told Detlef Overbeek last weekend I would take up the
>> 3.2.4 release task in July if Florian didn't find the time by then.
>> I have still 2 AI conferences where I must speak, but then there will be
>> time.
>
> Good. The first things to consider:
>
> - is it worth bringing out a 3.2.4 that is essentially the state of mid 
> 2024  in mid 2026 ? As discussed in other threads, I think it is best to 
> reopen the merge window ASAP, to avoid releasing anything that contains 
> no fixes at all for anything that has been fixed in the last 2 years 
> (and reported for even longer).

Was planned.

> - A policy for maintaining a release (candidate(s)) branch at a distance 
> of the fixes branch. With SVN we initiated mergetracking for that. I 
> don't know if GIT provides anything, but considering the current, manual 
> scripted trunk->fixes merge management, it at leasts needs some work.  
>  So  I'd urge you to consider finding some automated way to manage 
> that. Don't underestimate the number of last minute fixes that will 
> confuse you otherwise.

That's easy.

But you should expect some additional gitlab rules to make this possible.

Nothing blocking, but some more discipline will be needed:

Our current libertine way of developing will need to be somewhat curtailed.

> - maybe do another RC asap, and announce it properly this time, so that 
> there is actual feedback.

Was part of the plan already.

>> Graeme - or anyone else interested in moving things forward: I'm 
>> interested in ideas for making the CI/CD come up with release 
>> artifacts for the major platforms: windows, linux and mac.
>>
> Mac, Windows, Linux. In that order, to avoid kicking in already open doors.

Order makes no difference. Either they're all available, or none is.
That's simply how gitlab automation works.

Michael.