[fpc-devel] Preparing FPC 3.2.4 RC2

[Marco van de Voort]

Op 20-4-2026 om 15:58 schreef Michael Van Canneyt via fpc-devel:
>
>
> 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. 

I'll review my own revisions, and post them there.

For the backlog, you might want to look 
at https://www.stack.nl/~marcov/mergelogs32/

Also have a look at revisions attached to 
https://gitlab.com/freepascal.org/fpc/source/-/work_items/40432 and 
https://gitlab.com/freepascal.org/fpc/source/-/work_items/39481, that 
might have legal precedence (adding headers to all files, important for 
debian!). There might have been even more  rounds of such bugreports 
though.

As for the mergelog webpage, the summary of revisions for each category 
is on the top of each category subpage.  That still requires some 
scrutiny, you might have to filter some dotted units related and other 
mass commits, but the descriptions are right there too, and most commits 
are relevant. I usually clean that up when I'm actually trying to merge 
a category.

- Any category that starts with rtl- or fcl- is at least worth looking 
at. Exception: fcl-passrc,fcl-web, fcl-js, see below

-  vcl-compat is a special case, and you already had plans for that. 
Specially uitypes is important, since that is a conduit between FPC and 
the base graphical defines of the LCL graphics unit. Making sure that is 
as complete as possible helps lazarus clean out cruft in time.

- Winunitsbase, miscpackages are also a good (and fairly) easy categories.

- classes unit, sysutils "rtlobjpas' (which is rtl/objpas minus sysutils 
and classes) require more management, but are also among the most used 
units.

- paszlib, regex(p)r are typically always bugfixes and desirable.

- fgl is mostly bugfixes, but might touch aspects of the language. I did 
merge them in the past, usually no problem.

- openbsd contains patches to get the libc based RTL functioning again.

Most of these counters for relevant categories were zero or close to 
zero when 3.2.2 was released.

Then there are the categories that are normally merged, but hit a snag 
this cycle.

- rtl-console, FV and IDE are probably interwined. I don't know the 
exact desirability of its merges. The distance became to great.  The 
direct reason IIRC was unicode work, and Nikolay said not to merge.

- anything to do with fcl-passrc, fcl-web, fcl-js etc. It was all too 
intwined with the pas2js development, which was not stable at that 
moment.  I'm not entirely sure about fcl-json, I think I merged that longer.

For maximum efficiency you will want to merge in order.   Note that 
might depend on your ETA for the next major release.

With x..y.4 releases there is usually a sense that it is the last of a 
series. So merging can be a bit more brute force (committing trunk 
files, hand modifying), but then there was always an agreement to merge 
the major branch as soon as possible (happened 6 months after 3.0.4), 
and work towards main branch stabilisation and finishing of features.

If the next major branch is delayed, due to the main branch contents, or 
infrastructural work, that would make merging for a next minor (x.y.6) 
cycle more difficult.

So I wouldn't burn any ships unless you have a rough agreement on a 
major branch date.