Status of FPC 3.4.0 or FPC 4.0.0 [major release]

[marcov]

This discussion doesn't lead anywhere as usually because "Only volunteers work on this project. Their time is limited. They can't be forced to do the release. To fix the bugs." So unless project leader collects some money and hire some paid programmers then nothing will change. Only excuses remain.

This is just "a hobby" project. If anyone uses this as a professional tool then one should reconsider his approach and use something better suited. Simply Lazarus/FPC is no match for other bigger projects and programming languages like C#/.NET, Python, JavaScript/TypeScript, Rust and list goes on. There are some smaller projects which are more active than this project. So it is just about people.

That is not "hobby" vs paid programmers, that is "hobby" vs corporate behemoths. Two paid programmers won't tilt the balance against Microsoft (C#/.NET Typescript etc).  And then I'm not even going into the denigrating "hobby" designation.

Perhaps one solution would be to replace people with AI agents

I sometimes feel like they already invaded this thread

If there is not enough manpower then just use unlimited AI agents.
For example Kimi-K 2.5 can use agent swarms https://www.youtube.com/watch?v=FfCqINSD8Tc
Just give them a task like make a new release. Implement Gtk3/4 for Lazarus/FPC and voila here you have it. It is just about right prompt

If I can divine a magical right <x> I would play some major lottery, and get paid programmers that way.

AI agents won't complain about not enough spare time or motivation.

But like paid programmers they work for a fee. That needs to be covered. Also someone needs to

I wouldn't be surprised that in the long run, AI is actually more useful as assistive technology for smart cross-referencing when hunting for bugs than for new code generation.

So if there are here some people who need to have good Pascal compiler with support for modern technologies then just team up and bring us a new tool. We other passive users would welcome such activity.

You can always keep hoping that somebody else will do the job. But at a certain point one must transition from passive to at least somewhat active.

[PascalDragon]

The problem is that one area that was touched was the PPU loading which is very central to the compiler and it turned out that the rework for it done by MvC had not covered everything necessary while working on it. While it did improve quite some it led to catastrophies in other corner cases.

Another issue is one where I'm at fault myself and that is breaking the LLVM backend when introducing support for function references. I'm since then working on a solution, but it's a) not easy, b) I don't have always have the necessary time and c) I don't always have the motivation to work on it. Thus that is taking more time than it might have during my time at university.

Is it accurate to say those problems came about due to the addition of new features ?  (obviously function references are a new feature but, the reason for the PPU changes/modifications you left unspecified.)

The PPU rework was not due to a new feature, but due to MvC trying to fix compilations bugs in complex Delphi software of his company. It's been known for a long time already that the unit loading mechanism needs a rework but no one wanted to tackle it due to it being that central to the compiler. Well, MvC decided to tackle it and while it did indeed fix his own situation it also showed bugs that had been hidden by the previous implementation or introduced new bugs due to an unclear view of all the teeny tiny details of the compiler.

The main problem is that we don't have a release manager with sufficient time.

This is a straightforward and clear response to the topic.

but what happens when the release manager finds it necessary to direct the core developers to stop working on adding features, and instead direct their efforts to fixing bugs?

There is no one who can tell anyone anything.

[440bx]

The PPU rework was not due to a new feature, but due to MvC trying to fix compilations bugs in complex Delphi software of his company.

Thank you PascalDragon for that additional information.

[Martin_fr]

The PPU rework was not due to a new feature, but due to MvC trying to fix compilations bugs in complex Delphi software of his company.

Thank you PascalDragon for that additional information.

And I can confirm from my experience that 3.2.3 does occasionally (often enough) "forget" to recompile something, and then links outdated code into the app. I haven't fully tested if the changes fixes all of that, but it was broken before. And IMHO (as annoying as it may be), recompiling something that didn't need it versus  not compiling something that needs it... Should have a clear winner. Getting it perfect will be even better...

[440bx]

And I can confirm from my experience that 3.2.3 does occasionally (often enough) "forget" to recompile something, and then links outdated code into the app.

with v3.2.2, I have on rare occasions experienced situations where a unit that should have been recompiled wasn't causing the app to be re-linked with an "obsolete" unit.  I never reported those instances because I never found a way to reliably reproducing the case with some practical test code and also because they happen quite rarely.

I believe, though I could easily be wrong, that it occurs when a unit has include files that have been modified.  It seems that sometimes the fact that the include file is modified does not "bubble up" to the unit that includes it thus causing the problem.

I'm not sure but, I suspect there might be a race condition involved in the problem because building a second time, so far, seems to always eliminate the problem.

Anyway, since the fix is so simple, i.e, re-building a second time, it is barely a minor inconvenient.

[Martin_fr]

Anyway, since the fix is so simple, i.e, re-building a second time, it is barely a minor inconvenient.

If you notice... If you keep searching for the bug, because the attempted fix didn't help... And then time goes, and eventually you notice that your fix from an hour ago was perfectly fine ... Most of the time, its 5 to 10 minutes loss (today it was a bit over 5 minutes)

[Fred vS]

And I can confirm from my experience that 3.2.3 does occasionally (often enough) "forget" to recompile something, and then links outdated code into the app.

The same applies here, and less rarely: if you modify something in an .inc file, the changes are ignored during recompilation most of the time (if the -B fpc parameter is omitted)..

[Martin_fr]

And I can confirm from my experience that 3.2.3 does occasionally (often enough) "forget" to recompile something, and then links outdated code into the app.

The same applies here, and less rarely: if you modify something in an .inc file without the -B fpc parameter, the changes are ignored during recompilation most of the time.

For me its normal units, no inc files. As far as I can see, I think its mostly if generics are involved.

[Martin_fr]

Well, I just read this https://lists.freepascal.org/pipermail/fpc-pascal/2026-February/063102.html

If it can happen after 10 years, then FPC still has a lot of time... SCNR

[Fred vS]

Well, I just read this https://lists.freepascal.org/pipermail/fpc-pascal/2026-February/063102.html

If it can happen after 10 years, then FPC still has a lot of time... SCNR

Perhaps, or follow the pace of MSEide-MSEgui: one release every 6 months...

 

[Ten_Mile_Hike]

The solution is SIMPLE. Without changing a single byte of code post a download entitled FPC 5.0.0. Problem solved 

[LV]

The solution is SIMPLE. Without changing a single byte of code post a download entitled FPC 5.0.0. Problem solved 

It appears that we have identified a suitable candidate for the position of Release Manager. 😀

[dbannon]

If it can happen after 10 years, then FPC still has a lot of time... SCNR

Perhaps, or follow the pace of MSEide-MSEgui: one release every 6 months...

Or even Lazarus who seem to aim at 6 months too. Honestly, a release every 6 months must be massively easier to manage than one every five years. That is our problem now, its been put off for so long, the task is practicably unmanageable. And gets worse every day that goes by.

Davo

[robert rozee]

[...] Honestly, a release every 6 months must be massively easier to manage than one every five years. That is our problem now, its been put off for so long, the task is practicably unmanageable [...]

just to throw a spanner in the works...

given FPC 3.2.2 has been in use for the last 4.5 years without major issue, is there any need for a new release? aside from the Debian problem, of course... but it is sounding like that can be addressed with just a repackaging of 3.2.2.

sure, the FPC developers have been working for years on 'something' destined to one day become a 3.4.0 or 4.0.0 release, but besides those handful of developers, who needs this new version? FPC 3.2.2, as a compiler, seems to works just fine for many thousands of everyday users.


cheers,
rob   :-)

[dbannon]

given FPC 3.2.2 has been in use for the last 4.5 years without major issue, is there any need for a new release?

Yes, things get out of date. One example, fpc322 on Linux does not support the current version of SSL. While there are tricks to get around it, they will only be good for so long.

New hardware comes along too. Macs using ARM chips, Raspberry Pi Pico and ESP32 series for example. While its great we can support things like the DEC Alpha chip, lot more demand for new chips.

Davo