My pain points and an idea

with 3.2.2 the openssl unit is for version 1.1.x, for now, lots of distro removed openssl 1.1, even in slackware-current I can not upgrade to 3.2.4-rc1 just because it's come with openssl 3, I was stucked then...

my thinking:
is it possible to split to compiler and rtl/packages? after certain period of a release, 6 months or 1 year or by devel team thought, release a updated rtl/packages only version

for example: if we got 3.2.4 in 2026.04, then we may get next sub-release 3.2.4-2026.10 or 3.2.4-2026.12 for rtl/packages update only.

reasons:
1) we need library bondings came with fpc release
2) libraries are updating qicker and sooner
3) for a certain fixes branch, ex fixes_3_2, language features not changed a lot
4) for a production usage, refactor to a new compiler version/features is not very much
5) compiler devel can be more time flexiable, no stress for a new/stable release

yes, i understand there will be more work for additional merging and branches managements.

I didn't read all mails in list, not sure anyone else metioned this already.

Just a *thinking*, not *asking*, please ignore if it's pointless.

Op 15-4-2026 om 21:14 schreef baldzhang via fpc-devel:

My pain points and an idea with 3.2.2 the openssl unit is for version 1.1.x, for now, lots of distro removed openssl 1.1, even in slackware-current I can not upgrade to 3.2.4-rc1 just because it's come with openssl 3, I was stucked then...

Delete the openssl directory in
$PREFIX/fpc/$FPCVERSION/units/$FPCTARGET/  and simply add a copy of the units that you want to some dir that you include with -Fu.

my thinking: is it possible to split to compiler and rtl/packages? after certain period of a release, 6 months or 1 year or by devel team thought, release a updated rtl/packages only version

This is hard to impossible. And to even attempt it to for the benefit of a package (openssl) that is relatively standalone is counterproductive. It is doing something really hard to fix something really simple.

I would put some nuance to this answer:

Compiler and RTL are intimately bound. Splitting those is indeed next to impossible.

But packages and most utils are quite independent, with exception of the text-mode IDE, as it needs the compiler, and possibly the RTTI unit.

It's not worth it for a single package, but given that there are many packages, it could be worth it to split them from the compiler/rtl in order to speed up releases of packages: take the latest released compiler and bundle it with the packages.

Small exceptions aside, I build all package code to be usable with 3.2.2 as well, for the simple reason that I want it available in the lazarus IDE.

Michael.

Op 15-4-2026 om 21:37 schreef Michael Van Canneyt via fpc-devel:

But packages and most utils are quite independent, with exception of the text-mode IDE, as it needs the compiler, and possibly the RTTI unit.

rtl-objpas contains rtti  unit and there is vcl-compat with many incompat changes.

The rtti unit can be compiled for 3.2.2, it will miss some functionality, but it will still be available. The only thing it really relies upon from trunk is the actual extended rtti info, so people will get limited info.

vcl-compat indeed relies on some trunk compiler features (the JSON stuff), but probably not as many as you seem to suppose. Some IFDEFs will get us a long way. I developed most of it, so I'm pretty sure of this.

I'm not saying that everything will be easy, but it's definitely doable.

Michael.

Op 15-4-2026 om 22:23 schreef Michael Van Canneyt via fpc-devel:

And function references, custom attributes. Though that might be a matter of adding ifdefs:

C:\repo\fpc\packages\rtl-objpas\src\inc>fpc rtti.pp
Free Pascal Compiler version 3.2.2 [2021/05/15] for i386
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling rtti.pp
rtti.pp(27,2) Warning: Illegal compiler switch "FUNCTIONREFERENCES+"
rtti.pp(91,45) Error: Identifier not found "TCustomAttribute"
rtti.pp(91,61) Error: Type identifier expected
rtti.pp(91,62) Error: Error in type definition
rtti.pp(358,75) Error: Identifier not found "TCustomAttribute"
rtti.pp(361,50) Error: Type "TCustomAttributeArray" is not completely
defined
rtti.pp(385,18) Error: Illegal expression
rtti.pp(409,50) Error: Type "TCustomAttributeArray" is not completely
defined
rtti.pp(424,34) Error: Identifier not found "RTLString"
rtti.pp(424,14) Error: There is no method in an ancestor class to be
overridden: "ToString:<erroneous type>;"
rtti.pp(473,46) Error: Duplicate identifier "GetName"
rtti.pp(555,5) Warning: Constructor should be public
rtti.pp(582,18) Error: Illegal expression
rtti.pp(599,50) Error: Type "TCustomAttributeArray" is not completely
defined
rtti.pp(618,15) Error: Identifier not found "PExtendedFieldEntry"
rtti.pp(618,34) Error: Error in type definition
rtti.pp(619,18) Error: Illegal expression
rtti.pp(628,50) Error: Type "TCustomAttributeArray" is not completely
defined
rtti.pp(628,14) Note: Virtual method "GetAttributes:<erroneous type>;"
has a lower visibility (protected) than parent class TRttiObject (public)
rtti.pp(664,35) Error: Identifier not found "reference"
rtti.pp(664,45) Error: Error in type definition
rtti.pp(664,45) Fatal: Syntax error, ";" expected but "TO" found
Fatal: Compilation aborted
Error: c:\fpc\3.2.2\bin\i386-win32\ppc386.exe returned an error exitcode

Op 15-4-2026 om 22:23 schreef Michael Van Canneyt via fpc-devel:

I merged most of it up till the release freeze. I was particularly interested in the json stuff, but that is from after that date.

But at that time just before the release freeze, merging vcl-compat revs had increasingly become difficult due to entanglements.

Yes, I know.

In each case, if ever it comes to a split, it will be the packages as a whole, with some ifdefs to make it compile with whatever is then the release compiler. So definitely no cherry-picking operation, that seems like a recipe for disaster to me...

Michael.

I try to compile rtl and packages in branch:release_3_2_4-branch with 3.2.2 i386-win32/win64, both compiling passed. branch:main not tested and failure is predictable...

forgot the rtl part is tightly binded with compiler, so my idea may change to: "how about split to core compiler+rtl and packages?"

many years ago, linux kernel 2.6 taken too long to release, then they change devel modal looks like a *rolling mode*. after all, the software world evolutions faster and faster, the *fixed mode* might not catch up in time.

As I said, I've had this idea for a long time.

We'll see what we can come up with for a fixed release schedule. I would prefer no split. But if that fails, then a split may become necessary.

Michael.