FPC 3.4 Release Date?

[nvitya]

Hi,

The last stable FPC is 3.2.2 on the freepascal.org from 2021.
Since then lot of good boards are there with RISCV64 architecture, which is not supported by the FPC 3.2.

I have to use an unofficial 3.3.x to target the RISCV64 - which is nice that is is supported and works well.

But not having a major release since years is pretty discouraging.

Are there plans creating a stable FPC 3.4.x anytime soon?

nvitya

[Wallaby]

AFAIK there's no plan for a new stable release right now—at least nothing that's been announced. It’s a bit of a shame, really. The compiler has seen loads of improvements over the years, but without regular releases, it’s easy for people to assume the project isn’t moving forward.

If you check the official site, the last release is from 2021, and the latest news item is about Niklaus Wirth’s passing. That doesn’t exactly give off an active or thriving vibe, and it might even make people think Pascal is dead.

I totally get that the devs are working on this in their spare time and out of passion, and I really respect that. But more frequent releases would help a lot. It’d show the project’s alive and well, attract more users, and maybe even bring in some backing to keep things going strong.

[Martin_fr]

Currently there is a release candidate for  3.2.4  (that is the same fixes branch as 3.2.2). So that will be the next release.

[PascalDragon]

Are there plans creating a stable FPC 3.4.x anytime soon?

No, there is not. The next planned release is 3.2.4 and 3.3.1 is currently not in a state that would even remotely be considered releasable due to various issues it has.

[ALLIGATOR]

I would like to support the starter's topic in that at least fix versions of the compiler should be released more often, okay without new features, but at least with bug fixes

Releasing fix versions is cheap, isn't it?

[Thaddy]

No it isn't: platforms would need to be skipped and go out of sync with the "release", which would not be a release.
If it is just win/apples/nixes, maybe.

[ALLIGATOR]

Don't confuse the major version with the version with fixes. Or, to your knowledge, is version 3.2.4 being delayed solely because there are problems on some platform?

[Thaddy]

Yes. This has also been explained before. At least there is an RC1 for 3.2.4.
That means it is feature complete on all platforms.
Although I fear that 3.2.3 fixes is already out-of sync with RC1, because they did not re-base fixes to 3.2.5, what you normally do when you have a frozen RC. 
And the latter is simply bad release management and not related to the code.
I can imaginary see that 3.2.3 is ahead of the 3.2.4 RC1 and that creates a problem of their own doing.
Better to backport from the yet non-existent 3.2.5

[Fred vS]

https://about.gitlab.com/blog/tutorial-automated-release-and-release-notes-with-gitlab/
https://guidebook.devops.uis.cam.ac.uk/explanations/git-gitlab/gitlab-release-automation/

[Thaddy]

If you read that carefully that confirms my statement.
Note FPC release management does not follow the suggested rules for this release, but done so in the past like I wrote.
An RC needs s a frozen fixes and a rebase.

[PascalDragon]

I would like to support the starter's topic in that at least fix versions of the compiler should be released more often, okay without new features, but at least with bug fixes

Releasing fix versions is cheap, isn't it?

This is the first release since the switch from SVN to Git and not only do we have to iron out issues with the release management, but we also got a new release manager (fpk instead of marcov) and we're all working full time day jobs with the desire to have free time that's not related to FPC as well. So things are bound to be slow, no matter what you desire.

Also releasing fix versions is not cheap. Even if we would skip binary releases for targets that had a binary release in the previous release the source would still need to work correctly on such a target or the fix version can be considered worthless.