Hi,

Florian and me will be preparing RC2 of 3.2.4 together.

RC1 is meanwhile several years old, so we're going to update it with work since RC1 that can be merged.

To this end, we invite people to help us collecting possible candidates for merging. I created a task in the gitlab bugtracker:

https://gitlab.com/freepascal.org/fpc/source/-/work_items/41735

If there are commits with fixes that you think should be in 3.2.4, please add a comment with the SHA1 (short or long) of the commit that you think should be merged. We'll review them and merge what is applicable.

Remember, this is a fixes release:
Do not ask for new compiler/language feature commits, they will not be merged.

Michael.

Florian and me will be preparing RC2 of 3.2.4 together.

That sounds good to me, to get RC3 of 3.2.4 and then a release when possible. The currently open PRs seem to 100% target main, not 3_2_4 and few seem to be cleanly even able to land on main anymore after the many months of them sitting open, that's the trick, I think.

There is one that seems to be a fundamental win64 fix that if it's real, should be rehomed/re-cherry picked to 3.2.4:
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1289

W

On Mon, Apr 20, 2026 at 6:59 AM Michael Van Canneyt via fpc-pascal <

BST Warren Postma wrote

The currently open PRs seem to 100% target main, not 3_2_4 and

As they should. It's then up to the FPC team to backport (cherry-pick) them to a fixes branch.

few seem to be cleanly even able to land on main anymore after the many months of them sitting open, that's the trick, I think.

Correct. I'll be starting this week, going through all the open MRs and triage/label them for the authors to action, so we can get them back up to date (or closed).

Regards,
Graeme

As they should. It's then up to the FPC team to backport (cherry-pick)

them to a fixes branch.

This feels weird to me for some reason, maybe that's normal in this project, but it seems more Git-normal to not commit bugfixes straight to trunk. Is this a holdover from the svn days when that's the only workflow you had because svn branching was... broken?

W

On Tue, Apr 21, 2026 at 11:04 PM Graeme Geldenhuys via fpc-pascal <

No. But managing a branch for every change would basically mean thousands of branches. This is possible for projects like linux or whatever when there are people doing nothing else than managing branches. FPC does not have such resources. Despite this, I think also LLVM despite having huge support uses a cherry pick based approach to port fixes to stable branches.

Inbetween "we never use branches" and "infinite branches bad" is every sane git workflow.

Git flow, or something. stable, trunk, at least.

On Wed, Apr 22, 2026 at 11:29 AM Florian Klämpfl via fpc-pascal <