Status of FPC 3.4.0 or FPC 4.0.0 [major release]

[dsiders]

[...] main isn't even remotely in a release-worthy state due to various major issues [...]

It seems there is only a main and fixes branch and no experimental?
So it could be that by adding new features main could still even get further away from a release-worthy state instead of getting closer?

If two branches can't be handled properly... how will adding a third improve anything?

[Alexx2000]

Free Pascal dying and that's a sad fact. I think many developers who use FPC see this.

[runewalsh]

That which is falling should also be pushed.

[ALLIGATOR]

And in which direction is the push vector directed? 🤔

[avra]

Free Pascal dying and that's a sad fact. I think many developers who use FPC see this.

I don't 

[marcov]

Free Pascal dying and that's a sad fact. I think many developers who use FPC see this.

Activity goes up and down with time. Every low the end is predicted, but till now, none of the lows were the end.

[DonAlfredo]

IMHO, I think that it would be good to publish the blocking 3.2.4-issues, so we, as a community, can work on them to try to solve these and, when successful, get a much needed release.

[gidesa]

My obvious and fair question is what's the current status of FPC 3.4.0 or FPC 4.0.0 [major release]?

I'm rather confident in saying that there likely won't be a new major release in 2026. Not only hasn't 3.2.4 been released yet, main isn't even remotely in a release-worthy state due to various major issues (and no, not the inline ones).

Around a year ago, using Fpcupdeluxe, I installed a so called "Fpc 3.3.1" version. Maybe an alias for trunk version. So, in a year, was "3.3.1" improved on bugs fixed? 
Is there some bug list sorted by o.s, Windows, Linux, ecc.? With this, one could decide to risk using "3.3.1", or stop on 3.2.2   

[Martin_fr]

Around a year ago, using Fpcupdeluxe, I installed a so called "Fpc 3.3.1" version. Maybe an alias for trunk version. So, in a year, was "3.3.1" improved on bugs fixed? 

Yes, it is an alias for trunk, or "git main branch".

Yes, there were fixes within this year. (No I don't have the list / see git log)
But also, there were new bugs within this year.

Some of those new bugs may have also already been fixed, some may have been reported but aren't fixed, and some may not even be known.

3.3.1 / trunk changes all the time. And the amount of bugs in it goes up and down all the time. And as the discovery of each such bug usually takes some time (if they were known immediately, they wouldn't be pushed to git) which can be days but also can be many months, there is no telling how many bugs there currently are.

There may well be long periods with no significant new bugs, or there may be sudden rushes of lots of them, or there may be just a few over a long time... It's hard to tell. Usually, even for those bugs reported and fix, there are no statistics of the exact time they were added, or how long they were in the code base...

Also, those bugs are usually not too obvious. If they break the compiler or its test cases, then they wont live long. But that means, if you compile your app, it likely works... at first. It may be some time until you find the issue.

Of course, its also possible to be on the lucky site, and everything works for you.

Is there some bug list sorted by o.s, Windows, Linux, ecc.? With this, one could decide to risk using "3.3.1", or stop on 3.2.2

Only the official issue tracker. But as above, it wont be complete for todays 3.3.1.

Of course you can select your grace period. I.e. if you set the risk factor at 6 month, after which if a bug has not been reported, then there either isn't one, or you are considering it not a risk to your work. Then you can check a combination of git log and issue tracker. Select a commit 6 month prior to the last bug report you consider an issue for you, then cherry pick any fixes that have been done since and may affect you.

[kupferstecher]

It seems there is only a main and fixes branch and no experimental?
So it could be that by adding new features main could still even get further away from a release-worthy state instead of getting closer?

If two branches can't be handled properly... how will adding a third improve anything?

My thinking was less about adding a new third branch, but about that it could help to define that the main branch can not get any new features until it is (successfully) released, otherwise it could get more and more difficult to get it 'ready' for a release (too many too big changes). Also it might be possible that it'd be easier to backport selected new features to the last fixes instead of making the main release ready. But I have no insight and didn't want to speculate, so I just asked it as a question.
Now I guess there are things like release cycles with periods when "new stuff" is allowed and when only the 'making ready' is done. From forum posts of the last years it always seemed to me that the development is in the 'new stuff' phase. Thus my concern, that a release is actually getting farer away then getting closer.

[marcov]

My thinking was less about adding a new third branch, but about that it could help to define that the main branch can not get any new features until it is (successfully) released, otherwise it could get more and more difficult to get it 'ready' for a release (too many too big changes). Also it might be possible that it'd be easier to backport selected new features to the last fixes instead of making the main release ready. But I have no insight and didn't want to speculate, so I just asked it as a question.

This is pretty difficult, since the commits are not all small, but quite quickly you would encounter a commit that is  tied to massive rearrangements of parts of the compiler, and the whole principle breaks down.

[BSaidus]

Free Pascal dying and that's a sad fact. I think many developers who use FPC see this.

Are you serious ??
I do not see anything what you say.

[Bart]

My thinking was less about adding a new third branch, but about that it could help to define that the main branch can not get any new features until it is (successfully) released, otherwise it could get more and more difficult to get it 'ready' for a release (too many too big changes).

A feature freeze (which is what I think yu mean) would mean a new branch anyway, since the development of new features should not just stop until a release from the 3.3.1 branch is done (will likely become 4.0 release?), so a new developmen branch AKA as main will be needed.

Bart

[ron.dunn]

Free Pascal dying and that's a sad fact. I think many developers who use FPC see this.

I hope not, I'm a relatively recent convert Turbo Pascal user from 1.0, but seduced away by other languages. Now delighted to find a relatively sane language that has an in-built GUI and great TUI and IDE and a vibrant community.

My uninformed perspective is that new features are unimportant, but bug fixes are critical. If you do it the other way around, you end up as Windows 11.

[LV]

Free Pascal dying and that's a sad fact. I think many developers who use FPC see this.

An interesting perspective from a Double Commander developer. 🤔