Status of FPC 3.4.0 or FPC 4.0.0 [major release]

[marcov]

The development model is fix first in trunk, and then merge to fixes. The current trunk was IIRC branched off in summer 2018, so talk of starting to work directly in it is somewhat strange. Except for when fixes from trunk required extra work to merge, nobody has worked on 3.2.x directly since then.

I hope this makes clear that discarding trunk and continuing with 3.2.x is not a practical proposition. So if you want something fixes, first test fixes3_2, and if that fails test trunk.

If that  is not fixed in trunk/main, write a patch to add it  to trunk and put it in the bugtracker. If it is major work, you probably want to communicate with core about things to pay attention to, and how to present the results. If it really is a bug fix, you can then request to merge it to 3.2.x.  (but you can ask about the chances when discussing the fix that you are attempting).

Yes, response is slow etc etc, but this is simply the only viable route to get something changed.

Trying to micro manage release strategies without any intimate knowledge of the project and release procedures is utterly pointless. I haven't seen any new  practical implementable suggestion in this whole thread.

[Martin_fr]

Trying to micro manage release strategies without any intimate knowledge of the project and release procedures is utterly pointless. I haven't seen any new  practical implementable suggestion in this whole thread.

Because the thread is "reversed". It would need someone of the team to specify what work needs to be done (I.e. someone of the team to do the mgmt, and have the work done by others)

There have IIRC been one or two posts of people who might have offered to "help", by providing time to perform tasks. I don't know if they would actually turn into anything... From experience 90% of such offers don't follow through, but we never know if they don't get called.

Ok, your above quoted statement is still true, if the problem with the release isn't the work (as in labour on tasks like checking what needs to be still fixed, patching it, finding required merges, bisect, resolving conflicts, testing, .... which all can be helped to reduce final work by the team).

If the problem is that the release is not even managed at all, then yes nothing in this thread has suggested a solution.
If there is - within the team - no manpower volunteered (and actually produced / i.e. an unfulfilled promise of it does not count), then the release process (within the team) is dead. But actually, if that is the case, the only possible solution has been proposed inside this thread. If there will no longer be releases from within the team, then they must be done on the outside (aka fork).

So there needs to be a statement. Does time exist for the mgmt of the release by anyone in the team who can collect any work done, and based on that bring forward a release? Yes or no?

[plaza1518]

I haven't seen any new  practical implementable suggestion in this whole thread.

With all due modesty and deep respect for your achievements, I would nevertheless like to offer some criticism:

How can there be constructive suggestions if there is no definition of objectives?

If the objective is to create a new major version with new features every year, then we can discuss how this objective can be achieved.

If the goal is to maintain a specific (bootstrap?) version permanently (over several years), then this can also be discussed.

For an outsider, the current branches in the Git repository are not entirely understandable. Especially since there does not seem to be any strict guidelines that are being followed.

Currently, it's a case of “business as usual,” which is fine, of course, since it's your project. It just makes it difficult for users and new contributors to get started.

I can't thank you enough for spending your free time on this project. You and your work enable many programmers to implement their own ideas without having to go with the mainstream.

[ALLIGATOR]

No, what's crazy is that somehow buggy software has somehow become acceptable

To be honest, it's unclear how you can use FPC 3.2.2 and talk about stability 

[440bx]

In my humble opinion, that is the difference between theory and practice. Of course, it is easy to get a small, defined area “error-free,” but it is quite another thing to develop a large project “error-free.”

Before anything I'm going to state that I am fully aware of the extreme dimensional differences between FPC and the projects I am about to mention but, that only works in the favor of demanding bug-free software.

In the aerospace industry, the software projects involved make FPC look like a "hello world" class program, yet those software projects are only released when they are, at least believed to be, bug free. 

There was a bug in the Boeing 737 Max and it resulted in the grounding of the airplane, as it should have.

Airplanes are not the only devices where bug-free software is not only expected but _demanded_.  Just about any device used in the medical industry is fully expected to be bug free.

The PC industry seems to be rather casual about the presence of bugs.  Likely because PCs are very rarely used to accomplish tasks where the stakes are significant.  As a result, it seems that some programmers now not only accept bugs but pretend that other programmers, for whom the continued presence of some bugs is unacceptable, should accept them. 

Bugs are not unavoidable, they happen even in the strictest testing environments but, they should NOT endure.  They should be found and fixed (hopefully the first time) and, that is NOT too much to expect.

Lastly, I don't care about Rust, Go or any other language interpreter/compiler where bugs are acceptable.  I don't use them, therefore I don't care and, more importantly, the fact that some project out there isn't doing it right, doesn't justify belonging to their club.  IOW, there doesn't seem to be much genius to copy in those projects.   That I know of, nobody has ever achieved excellence by copying mediocrity.

No, what's crazy is that somehow buggy software has somehow become acceptable

To be honest, it's unclear how you can use FPC 3.2.2 and talk about stability 

Chalk it to delusion  

[robert rozee]

i've just been trawling through the sourceforge pages for the various Lazarus/FPC targets.

the files fpc-laz_3.2.2-210709 and fpc-src_3.2.2-210709 seem to have shipped with every sourceforge release since the beginning of 2022, covering Linux64, Linux32, Win64, Win32. and similar versions (3.2.2) with macOS x86-64 (since 2022) and macOS aarch64 (since late 2024).


given the same version of FPC has been shipping for so long, is there really anything that needs fixing in it?

could it be argued that even if the 3.3.x and 4.x.x paths have stalled indefinitely, the needs of pascal programmers are satisfied by 3.2.2? true, android is not catered for, but how big (or not) is that market?


cheers,
rob   :-)

[plaza1518]

In the aerospace industry, the software projects involved make FPC look like a "hello world" class program, yet those software projects are only released when they are, at least believed to be, bug free. 

The comparison with aerospace, the medical field, and automation in general, where human lives are at stake, is very far-fetched.

If you work in this field, there is much more to consider than just an error-free compiler. In addition, the compiler can be kept much simpler in this area: a very limited range of permitted functions (no recursion, fixed memory allocation, no error events, etc.) and a precise definition of the target platform (OS, CPU, RAM, etc.).

With FPC, however, we are talking about an all-rounder. And as far as I know, FPC does not have the requirement to be “certified” for the areas mentioned above. Is that the case with Delphi? (It would be interesting to know.)

[440bx]

The comparison with aerospace, the medical field, and automation in general, where human lives are at stake, is very far-fetched.

It's not.  The difference is bug-free software is taken seriously in those fields unlike in the PC field.  It also demonstrates that expecting bug-free software is not a "fantasy" but a reality that MUST be met in serious applications.

In addition, the compiler can be kept much simpler in this area: a very limited range of permitted functions (no recursion, fixed memory allocation, no error events, etc.) and a precise definition of the target platform (OS, CPU, RAM, etc.).

Apparently you think that the compilers involved in creating the software of today's airplanes is "simple" ?  No error events ????  Obviously, you've got no idea.

FPC does not have the requirement to be “certified” for the areas mentioned above.

Good thing it doesn't because it "probably" wouldn't make it.   Just in case, are you suggesting that because it doesn't have to be certified in  any of those areas that makes it acceptable for the compiler to have bugs ?    if that's what you're saying, let me make it crystal clear that I totally disagree.

FPC should be bug-free because that reflects on the programmers that work on it.

[Martin_fr]

The comparison with aerospace, the medical field, and automation in general, where human lives are at stake, is very far-fetched.

It's not.  The difference is bug-free software is taken seriously in those fields unlike in the PC field.  It also demonstrates that expecting bug-free software is not a "fantasy" but a reality that MUST be met in serious applications.

This wasn't the only slip up. And Boing has shown how "serious" they take it. They are serious about making money.

And if you were right about it being really unconditionally expected: Airlines wouldn't buy from them. But airlines need some aircraft after all, otherwise they are out of business. So the quality demands are limited to whats avail.

All it needs, is to pass enough checks, to avoid liability. And even that is happily done with trickery if opportunity allows. And again, a large enough amount of the clients/costumers seems to be happy with that. At least they keep buying (not just with aircraft)

FPC should be bug-free because that reflects on the programmers that work on it.

Well, then reflect it on me too...

My contributions to Lazarus aren't bug free either. And for a variety of reasons (technical and personal and biological (e.g., the need to sleep)) some of them have (and will further) persisted for a long time. Longer than they should in a perfect world.

[plaza1518]

FPC should be bug-free because that reflects on the programmers that work on it.

Please excuse me, but I did not say that it would not be desirable for FPC to be error-free.

And I strongly assume that everyone involved in maintenance and further development is trying to make FPC as error-free as possible. I fully understand that this is only possible to a limited extent. Everyone involved invests their free time in this project, which they would certainly often prefer to use for other things. It makes a difference when a financially strong company can provide appropriate staff for such a project. That is simply not the case here.

And based on that, the questions arise as to what demands we as users can make on FPC and what support we ourselves can offer.

[marcov]

Because the thread is "reversed". It would need someone of the team to specify what work needs to be done (I.e. someone of the team to do the mgmt, and have the work done by others)

It is not really realistic for someone to go from nothing to be able to further something as complex as releasing a new version. This can't be explained easily. I did it for 16 years, and the status was murky sometimes even for me as non compiler developer, specially for the main branch releases (the x.y.0 releases)

It is however realistic to adopt some feature or issue and try to further it, learning to debug the compiler etc. Then it is a matter of persistence (as done by Gareth, Margers and another two regular contributors of merge requests on gitlab, that all joined or got really active since 3.2.0/.2 period. So it is possible despite all the doom-saying, you just need to persist, and set yourself realistic goals, both complexity and time wise.

Doing non compiler work is much easier, even I can do it !

There have IIRC been one or two posts of people who might have offered to "help", by providing time to perform tasks. I don't know if they would actually turn into anything... From experience 90% of such offers don't follow through, but we never know if they don't get called.

As said, it is quite difficult to give the uninitiated jobs that lead to short term change, as the blockage is mostly in the compiler.

But at the very least I would expect all people that want to make comments to have at least track trunk and  fixes branches and have a binary release of 3.2.2 to test with. Preferably on more than one target (e.g. Linux and windows)

Ok, your above quoted statement is still true, if the problem with the release isn't the work (as in labour on tasks like checking what needs to be still fixed, patching it, finding required merges, bisect, resolving conflicts, testing, .... which all can be helped to reduce final work by the team).

If it were that easy, I'd have a go at it. But if the blockage is in the compiler, that is hard even for me. And people would have to be willing to communicate (see my earlier remarks about more release  management) about it.

If the problem is that the release is not even managed at all, then yes nothing in this thread has suggested a solution.
If there is - within the team - no manpower volunteered (and actually produced / i.e. an unfulfilled promise of it does not count), then the release process (within the team) is dead. But actually, if that is the case, the only possible solution has been proposed inside this thread.

I think that is effectively the case. I see Florian merge some revs 2 or 3 a year, but communication about the status is effectively zero.

If there will no longer be releases from within the team, then they must be done on the outside (aka fork).

The first half of that sentence is never that absolute. You (and I) simply don't know if it restarts again. But forking is also pointless for the uninitiated (other than robo building what is there without much added value).

So I would try to keep the sentiment positive, and simply start doing what you can.

So there needs to be a statement. Does time exist for the mgmt of the release by anyone in the team who can collect any work done, and based on that bring forward a release? Yes or no?

I did some merging in fall 2024, as Florian seemed to gear up for a release with christmas/ny 2024/2025. The release branch was frozen, and I stopped merging. That is to my knowledge still the state.

So I myself have no idea, as I have seen no communication about the subject, but as you might know, I have had trouble with core messages the last half year, so I might have missed something. Maybe Pascaldragon knows the current status better.

Quite a lot of non compiler stuff was merged, more than for the typical .4 release. However parts that saw changes due to pas2js (so web technologies like fcl-web, json and fcl-passrc) lag, because the large number of intwined commits and usage of new compiler features.  Also some of the more recent work to vcl-compat can't be merged for that reason (using 3.3.x features).

I also from time to time update https://www.stack.nl/~marcov/mergelogs32/ with the list of unmerged revisions.  The difference between fixes and trunk is currently in the magnitude of 13000 commits. I hope that that illustrates the complexity of releasing.

[marcov]

2 - Code not requiring new features and that have been stable for a long time with very few patches, here I think about things like \packages\fcl-db, that has not seen breaking changes and compiles with 3.2.2. These codes would be nice to have in a 3.2.X version BEFORE they get refactored with "improved features".
These should come in the stable distribution.

Existing code rarely gets refactored with improved features. The new features are mostly in new packages like vcl-compat and the rtti unit in rtl-objpas. Some base support is in classes (tthread), but that is relatively small, and must do fixes are easily migrated by hand.

The list of unmerged fcl-db features is here: https://www.stack.nl/~marcov/mergelogs32/fcl-db.html  Some of the larger commits only rename char -> ansichar in preparation of unicodestring based RTL, and there are a series of commits that only spell fixes in comments and camelcasing the unit name.

[Martin_fr]

@Marcov:

Yes there is some (large) gear up. And I did state: 90% of the offers usually will go silent if they are called. (Probably more than 90%).

But also, it hasn't been tried. (And as, see below, it needs an yet unwritten fix, it may not be worth trying)

And also, very little (and even that, only vague) had been communicated.

The "most definite" statement was "problem with Mac / arm". => But that could be anything
- From: A big fix in the depth of the compiler itself (affecting all from parser, to code gen and between)
- To: find the 3.3.1 commits and get them merged

The latter is certainly hard, if you don't understand the code... But, find (if it exists) can be done with a lot less knowledge required. You mainly need the ability to build, and bisect. And then some trial and error, as it may be a combination of several non consecutive commits...
That is majorly time consuming, but does not require a complier dev. Yet "can be done" still requires someone with substantial skills.

Merging, would be daunting without background on the code. It could still be do-able, but it may not. You can get surprisingly good understanding of a change by using git blame and similar tools. But again very time consuming.

But about time consuming: If someone take a year for that, who is to say that wouldn't speed things up? (Unfortunately).


If however, as by your statement, fixes to the compiler may still have to be written (i.e. aren't even present in 3.3.1) then well yes, the amount of people who can help is indeed very very restricted.

But so far, nothing that was known to determine required skills.

[plaza1518]

I took the liberty of analyzing the contributions to the repository by author. I will only mention those individuals who have contributed more than 10% commits since January 1, 2025, without forgetting that the contributions of all other participants were equally important.

• Michaël Van Canneyt
• florian
• Pierre Muller
• Margers
• Nikolay Nikolov

As an outsider, I cannot discern any structure in terms of who is “important.” In any case, this is likely to be the core of the FPC developers. It seems to me that everyone has an equal right to influence the progress of the project, depending on how many merits they have earned.

Can these people get together and discuss how the project should be continued? Should there be new major versions at all? And many more questions...

Based on the outcome of these (presumably several) discussions, can these people then decide who can contribute what, and in particular, where “external” people can contribute?

[440bx]

This wasn't the only slip up. And Boing has shown how "serious" they take it. They are serious about making money.

The problem isn't their being serious about making money.  The problem is making money by cutting corners and Boeing started to engage in that practice (cutting corners) after it acquired McDonnell-Douglas which eventually became non-profitable because they tried harder to make money than build reliable airplanes. 

And if you were right about it being really unconditionally expected: Airlines wouldn't buy from them. But airlines need some aircraft after all, otherwise they are out of business. So the quality demands are limited to whats avail.

It is unconditionally expected.   What is NOT unconditionally expected is for human beings never to make mistakes, that is not expected nor can it ever be expected.  Mistakes do happen but it is fair to _expect_ them to be corrected, it is also fair to expect they'll be corrected in good faith and in a reasonable amount of time (not years!.)

All it needs, is to pass enough checks, to avoid liability. And even that is happily done with trickery if opportunity allows. And again, a large enough amount of the clients/costumers seems to be happy with that. At least they keep buying (not just with aircraft)

and that is _unacceptable_ and, I'd go even further and consider it criminal.    Yes, I hold Boeing responsible for the deaths of hundreds of people in their pursuit of lining their pockets with dollars.  It is shameful that some of the people involved in the MCAS debacle didn't end up behind bars.

FPC should be bug-free because that reflects on the programmers that work on it.

Well, then reflect it on me too...

My contributions to Lazarus aren't bug free either. And for a variety of reasons (technical and personal and biological (e.g., the need to sleep)) some of them have (and will further) persisted for a long time. Longer than they should in a perfect world.

Here are a couple of questions:

1. did you release the software knowing the bugs were there and not declaring their presence ?
2. did you willingly fail to correct bugs you were responsible for after they were reported in spite of the fact that you could have reasonably done so ?

If you answer "yes" to either one of those questions then I state that such behavior reflects very poorly on you.

Let's state the obvious: someone competent and acting in good faith will eventually, within practical time frames (NOT 5 years) fix the bugs in their software.

I refuse to accept the mediocrity of others as a valid reason to accept it widely and as something "normal".

A normal and steady amount of dedication is all it takes to produce bug-free software.  Corollary: if the software had been appropriately tested, it's quite likely it wouldn't be as buggy.