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

[Marco van de Voort]

Op 15-4-2026 om 20:09 schreef Marco van de Voort via fpc-devel:
>
>
> It is the exact opposite of my central idea. Which is "More release 
> workers, less release workflow designers". Specially not workflow 
> designers that never took any responsibility for the release project 
> before.

Some bits that I considered after the last mail:

A) For the people that want to play the release automation card:

1) Realise that release automation is _NOT_ the bottleneck in the 
release process. Actually making sure the branch would produce a 
workable release is the bottleneck. This is usually either ignored (but 
any automation will /surely/ help?) or suggesting to skip that step 
outright. But skipping this step is not really about releasing any more, 
but basically rebranding snapshots as releases. And that is a token 
change only, since snapshots are already provided, and obviously don't 
satisfy the need for a release (or we would not be having this discussion)

2) If you _still_ want to do automation, please start with the Tier 1 
platforms in this order: (1) Mac OS X (2) Windows (3) Linux.  As most 
Linux detail release work happens in the distribution packaging, putting 
it first is too low a bar.  OS X in recent history has been  the most 
problematic of the Tier 1 targets, so anything that you can do to keep 
the current live branches up to date with the current (annual) iteration 
of OS X would be hugely beneficial. That is no disrespect to Jonas btw, 
it is simply the reality of a annual release that nearly always breaks 
something.  And those breakages are often non trivial. Windows has had 
its problems too (let's not forget the SEH32 rework that held up the 
3.2.0 release), but those are increasingly more isolated due to having 
internal binutils and a very stable ABI/API.

If you want to "fix" releasing and you own an up to date Mac, that is 
surely where the efforts should have the best ROI. Much more than 
writing a few makepack alike scripts.

3) Similar claims (CI, automated releases) were made during the 2021 
gitlab migration by Michael and Joost. It would be good to find out what 
became of those efforts. At least I never heard of them again.

B) Another fundamental flaw of plans like yours is that the assumption 
that the relation between main/trunk and release branches (of any 
policy) is simply a matter of selecting a few winner revisions to merge, 
and ignore the rest.

After 1-2 years however most compiler revisions are however attached to 
major reworks or restructures of the compiler.

Your process doesn't provide any tools to solve that problem, it merely 
reiterates an over idealistic view of cherry picking random unrelated 
versions to release branches.   A prime example is the said loadppu 
rework of may 2024 that made the main branch unstable after more than 5 
full years of development (the 3.2.x branch was branched from the main 
branch in summer 2018 iirc), making a speedy major branch release hopeless.