Re: Preparing FPC 3.2.4 RC2

Florian Klämpfl via fpc-pascal <[email protected]> Wed, 22 Apr 2026 20:22:25 +0200
Newsgroups gmane.comp.compilers.free-pascal.general
Message-ID <[email protected]>
--===============6694821314103674762==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C7FE6C27-D10A-404B-9D41-CDEAA7226372"


--Apple-Mail=_C7FE6C27-D10A-404B-9D41-CDEAA7226372
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Am 22.04.2026 um 20:01 schrieb Warren Postma via fpc-pascal =
<[email protected]>:
>=20
> >As they should. It's then up to the FPC team to backport =
(cherry-pick) them to  a fixes branch.
>=20
> 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?

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.

>=20
>=20
> W
>=20
> On Tue, Apr 21, 2026 at 11:04=E2=80=AFPM Graeme Geldenhuys via =
fpc-pascal <[email protected] =
<mailto:[email protected]>> wrote:
>> On Tuesday, 21 April 2026 00:16:46 BST Warren Postma via fpc-pascal =
wrote:
>> > The currently open PRs seem to 100% target main, not 3_2_4 and
>>=20
>> As they should. It's then up to the FPC team to backport =
(cherry-pick) them to=20
>> a fixes branch.
>>=20
>> > 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.
>>=20
>> Correct. I'll be starting this week, going through all the open MRs =
and=20
>> triage/label them for the authors to action, so we can get them back =
up to=20
>> date (or closed).
>>=20
>> Regards,
>>   Graeme
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> fpc-pascal maillist  -  [email protected] =
<mailto:[email protected]>
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> _______________________________________________
> fpc-pascal maillist  -  [email protected]
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


--Apple-Mail=_C7FE6C27-D10A-404B-9D41-CDEAA7226372
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>Am 22.04.2026 um 20:01 schrieb Warren Postma via =
fpc-pascal &lt;[email protected]&gt;:</div><br =
class=3D"Apple-interchange-newline"><div><div dir=3D"ltr"><div><div>&gt;As=
 they should. It's then up to the FPC team to backport (cherry-pick) =
them to&nbsp;&nbsp;a fixes branch.<span =
class=3D"gmail-im"></span></div><br></div><div>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?</div></div></div></blockquote><div><br></div>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.<br><br><blockquote type=3D"cite"><div><div =
dir=3D"ltr"><div><br></div><div><br></div><div>W</div></div><br><div =
class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" =
class=3D"gmail_attr">On Tue, Apr 21, 2026 at 11:04=E2=80=AFPM Graeme =
Geldenhuys via fpc-pascal &lt;<a =
href=3D"mailto:[email protected]">[email protected]=
l.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">On Tuesday, 21 April 2026 00:16:46 =
BST Warren Postma via fpc-pascal wrote:<br>
&gt; The currently open PRs seem to 100% target main, not 3_2_4 and<br>
<br>
As they should. It's then up to the FPC team to backport (cherry-pick) =
them to <br>
a fixes branch.<br>
<br>
&gt; few seem to be cleanly even able to land on main anymore after the =
many<br>
&gt; months of them sitting open, that's the trick, I think.<br>
<br>
Correct. I'll be starting this week, going through all the open MRs and =
<br>
triage/label them for the authors to action, so we can get them back up =
to <br>
date (or closed).<br>
<br>
Regards,<br>
&nbsp; Graeme<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
fpc-pascal maillist&nbsp; -&nbsp; <a =
href=3D"mailto:[email protected]" =
target=3D"_blank">[email protected]</a><br>
<a =
href=3D"https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal" =
rel=3D"noreferrer" =
target=3D"_blank">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fp=
c-pascal</a><br>
</blockquote></div>
_______________________________________________<br>fpc-pascal maillist =
&nbsp;- =
&nbsp;[email protected]<br>https://lists.freepascal.org/cgi-=
bin/mailman/listinfo/fpc-pascal<br></div></blockquote></div><br></body></h=
tml>=

--Apple-Mail=_C7FE6C27-D10A-404B-9D41-CDEAA7226372--

--===============6694821314103674762==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

--===============6694821314103674762==--