Status of FPC 3.4.0 or FPC 4.0.0 [major release]

[Fred vS]

Because all FPC core developers are very intelligent people and they have finally understood that the time has come to act NOW, without looking for excuses (even lack of manpower). 

OK   
BTW, I briefly checked your https://github.com/fredvs/freepascal-ootb
Nice! You should coordinate FPC releases!

If I could help, it would be my pleasure, but the most competent person is Don Alfredo.

[PascalDragon]

In addition, I am not sure what to do with issues for older versions of the compiler — for example, for 3.0.0 or something... If its behavior is no longer reproduced in FPC[main], why keep it open?
This is a question for the developers—please provide some guidance on how best to deal with such issues related to older versions of the compiler.

Because it's not always known that if one stumples upon an issue in the code and fixes it (maybe even by accident by changing something else) that there was already an issue in the bug tracker. So if users find that an issue is indeed already solved (especially if it was reported against an older version) then please don't hesitate to remark that in them so that they can be closed (and maybe their test code if available be added to the test suite).

from reading this thread, it seems that the major issue with FPC progress is "feature creep".

Then you didn't read the important messages. The main problem is man power for release management, especially someone that coordinates it. Up until 3.2.2 that was marcov, but with the switch to Git he decided to step down with fpk taking up the job, however it seems that his free time is very limited as well.

I propose that all FPC core developers cease work on the main FPC branch for one month and focus exclusively on branch 3.2.4.

Us core devs work on this in our own free time and due to our own motivation. You (or anyone) will not be able to force any of the core devs do that.

[Fred vS]

[

I propose that all FPC core developers cease work on the main FPC branch for one month and focus exclusively on branch 3.2.4.

Us core devs work on this in our own free time and due to our own motivation. You (or anyone) will not be able to force any of the core devs do that.

 

[LV]

What we’re seeing right now in the Lazarus + FPC ecosystem — the growing tension between the community and the core compiler developers after the long silence following FPC 3.2.2 — is actually nothing special. It’s a classic problem of mature open-source projects.

Python’s history shows this very clearly.
And without conscious governance and honest communication, the same story repeats sooner or later — regardless of the language.

[vfclists]

Because all FPC core developers are very intelligent people and they have finally understood that the time has come to act NOW, without looking for excuses (even lack of manpower). 

OK   
BTW, I briefly checked your https://github.com/fredvs/freepascal-ootb
Nice! You should coordinate FPC releases!

If I could help, it would be my pleasure, but the most competent person is Don Alfredo.

We have been down this path a number of times but from the way I see it comes down to manpower and priorities.


1. How much of the work needed involves bringing the libraries up to date as opposed to adding new features to the compiler. I remember bring up this issue years ago. It is still a valid one?

2. How much manpower does the project have? How many core committers, how much free time can they devote to the needed work?

3. Is MacOS that important, is that popular, or is it the aarch64 variant that needs more work? Sorry Mac Guys. I understand that FreePascal targets a number ofarchitectures, too many perhaps. Does the project need to cover all architectures?

4. Is there a corporate entity that runs the project, and might be able to attract more funding and donations?

5. Does it need to hire full time developers, which is related to the previous point?

I don't know much about these aspects, but it may be time for those with more knowledge to give these issues are harder look, because this is where "we" are.

[Thaddy]

3. Is MacOS that important, is that popular, or is it the aarch64 variant that needs more work?

Yes it is. for multiple reasons:
1. Intel Macs disappeared some time ago, all hardware is ARM/AARCH64 for quite some time, already four processor generations
2. Intel Macs are supported but are really legacy hardware
3. The Mac users form quite a big part in the community, much bigger than you think.

So there is good reason to withhold a release if one of the main platforms is not up to scratch.

[marcov]

1. How much of the work needed involves bringing the libraries up to date as opposed to adding new features to the compiler. I remember bring up this issue years ago. It is still a valid one?

It was not valid back then either. First, the question in itself is already an oversimplification. Not all work to the compiler are pure additions, it is the restructuring and rewriting of parts of it that is associated with it that are the big rearrangements.

Second, does it really matter if manpower can't be directed towards a subject ? As I said before, there is nothing to manage here, there is middle management enough.

2. How much manpower does the project have? How many core committers, how much free time can they devote to the needed work?

Varies, varies.

3. Is MacOS that important, is that popular, or is it the aarch64 variant that needs more work? Sorry Mac Guys. I understand that FreePascal targets a number ofarchitectures, too many perhaps. Does the project need to cover all architectures?

It is that important. No we don't need to cover all the architectures, but the must release platforms are simply the top three targets that is developed for. Windows as number 1, OS X as number 2, and Linux as server platform.  And since Apple is all into ARM now, that means ARM. (just like it was powerpc one and an half decade ago)

4. Is there a corporate entity that runs the project, and might be able to attract more funding and donations?

There is a foundation. But that seems to spend its money on keeping up with the Joneses, chasing whatever technology is in the news.

5. Does it need to hire full time developers, which is related to the previous point?

Yes, it needs to. No it can't

I don't know much about these aspects, but it may be time for those with more knowledge to give these issues are harder look, because this is where "we" are.

This is constantly being re evaluated, and as said, the problem is not that the project misses middle management. It misses workers.

[gidesa]

3. I understand that FreePascal targets a number of architectures, too many perhaps. Does the project need to cover all architectures?

That huge number of targets is a very strong point for Fpc. Version 3.2.2 is good and stable for all targets, I think.
Indeed I see that some bugs are declared for Windows 7, that is a version 15+ years old no more supported by nobody. These tickets should be directly cancelled/closed, leaving support only for last 2 versions: Win 10 and Win 11.
But it's true that 5-6 years ago, when 3.2.2 was released, Windows 7 was an o.s. with large diffusion....
I imagine that many others, among the 1700+ open bug tickets, are related to very old version of Mac, Linux, etc. That is, a consistent number of tickets are only "history".

[robert rozee]

3. I understand that FreePascal targets a number of architectures, too many perhaps. Does the project need to cover all architectures?

That huge number of targets is a very strong point for Fpc. Version 3.2.2 is good and stable for all targets, I think.
Indeed I see that some bugs are declared for Windows 7, that is a version 15+ years old no more supported by nobody. These tickets should be directly cancelled/closed, leaving support only for last 2 versions: Win 10 and Win 11.

i suspect that many (most?) of those bugs "declared for Windows 7" will also still exist under Win10 and Win11. indeed, in theory it should be possible to target (for example) WinXP, on the assumption that any binary that runs on WinXP should also run on all later versions of windows.

code i develop targets (primarily) Linux and Win32, with all windows development done on Windows XP virtual machines. to date, i've had no problems reported of code written for XP not running on Win10 or Win11. i also use older releases of Lazarus (3.8.0 with FPC 3.2.2 is the newest) simply because i can see no good reason to justify migrating to anything newer.


cheers,
rob   :-)

[gidesa]

i suspect that many (most?) of those bugs "declared for Windows 7" will also still exist under Win10 and Win11. indeed, in theory it should be possible to target (for example) WinXP, on the assumption that any binary that runs on WinXP should also run on all later versions of windows.

code i develop targets (primarily) Linux and Win32, with all windows development done on Windows XP virtual machines. to date, i've had no problems reported of code written for XP not running on Win10 or Win11. i also use older releases of Lazarus (3.8.0 with FPC 3.2.2 is the newest) simply because i can see no good reason to justify migrating to anything newer.

It's in charge of ticket author to verify that the bug exists also on recent Windows, 10 or 11; it's not in charge of an organization/group that (could) officially close the support for Win 7, and has 1700+ tickets to work. 
Second, this forum is friendly and full of experts on various targets, so the one, that find a bug on an old o.s, can receive a good support, although unofficial.
I say this, because the compiler workgroup is small, but the list of o.s versions is more and more long. Of course, unbearable.
About the fact that a program working on Win XP (20 years ago) "will work" on Win 10, 11, etc., well, it's a big bet. Good that it's working well for you, but it's not the case to put a substantial effort on that old o.s.
Apart personal fun of compiler developers :-)   By the way, I understand that fixing bugs is not a funny work, especially on code written from others. So, for me it's perfectly clear why bugs remain in limbo for years.

[vfclists]

Yes, it needs to. No it can't

I don't know much about these aspects, but it may be time for those with more knowledge to give these issues are harder look, because this is where "we" are.

This is constantly being re evaluated, and as said, the problem is not that the project misses middle management. It misses workers.

By "workers"you mean work that a person capable of compiling FPC or Lazarus programs is capable of ie regular FPC and Lazarus users (like myself ), and that given the necessary instructions and tools they will be capable of checking and testing just by clicking or typing a few commands, then reporting their results to "middle management"?

If so do the necessary tools and instructions exist?

By tools I mean things like docker installations or virtual machines with the necessary compilers, IDEs and utilities installed with which the "workers" can carry out the necessary instructions from "middle management".

I say VMs because asking someone like me who knows nothing about MacOS or FreeBSD to test a problem on such systems is an exercise in futility.

[JuhaManninen]

If I could help, it would be my pleasure, but the most competent person is Don Alfredo.

That sounds like an offer.
Attention FPC core team! I understand you have limited resources. It means you should accept help from others. FOSS development should be dynamic. Some people loose their passion or get busy with other stuff. Other fresh and motivated people jump in. That's (FOSS) life.

[dbannon]

....
This is constantly being re evaluated, and as said, the problem is not that the project misses middle management. It misses workers.

Marcov, I have to disagree. Looking at the number of commits since the start of the year, says to me heaps of activity.

OK, its open source, people work on projects that suit themselves. And, clearly, in the past, the FPC devs must have made very many  altruistic contributions to make FPC the mature, stable product it is.  But is the problem now that most commits are dealing with something of particular interest to just its author ?  That is how open source works of course and its a good thing !  But with no one looking over the author's shoulder asking "have you tested that on XYZ platform" or "does that work in all modes" etc, some of those new features bring in bugs that probably don't affect the author but might hurt some other poor user who assumes the new feature is not just a point fix to solve a specific problem. Or might hurt some poor release manager ....

The truth is the gap between FPC322 and Main is just too great. It has been allowed to grow to an unmanageable degree and, apparently, is only going to get worse. That is the real problem.

Davo

[ALLIGATOR]

The truth is the gap between FPC322 and Main is just too great. It has been allowed to grow to an unmanageable degree and, apparently, is only going to get worse

I wonder    if there is anyone else here besides me who thinks the same way - that we should release FPC 3.2.4 right now, as is (well, maybe with a few minor tweaks), and forget about this old stuff

And make FPC [main] the next version 4.0/3.4.0, for example beta, and also release it right now, the beta
So that people can start adapting and adapting their code bases

[440bx]

I wonder    if there is anyone else here besides me who thinks the same way - that we should release FPC 3.2.4 right now, as is (well, maybe with a few minor tweaks), and forget about this old stuff

Count me in for getting that done (with, as you mentioned, the few minor tweaks needed to eliminate as many known bugs as reasonably practical in a small amount of time.)

And make FPC [main] the next version 4.0/3.4.0, for example beta, and also release it right now, the beta
So that people can start adapting and adapting their code bases

That part I can't subscribe to.  Personally, I have little interest for new features and a _much_ greater interest for getting a bug-free compiler. 

If I had my way, I'd let the compiler developers "play" with FPC main to their heart's content but, as far as FPC releases, I'd limit those to a steady stream of bug fixes for quite some time.

After that, I'd look at whatever features are in FPC main that sound really useful to enhance productivity and pick a handful of those to be included in the next major release.

"Secretly", I'd like to see a Pascal compiler match C feature for feature before adding any other features to it.  _After_ it matches C, feature for feature AND, it is reasonably bug-free (ideally, bug-free as far as it is known) then and only then, I'd consider new features _and_ only those that improve the programming experience, not the latest programming fad that makes a language "kewl".