Status of FPC 3.4.0 or FPC 4.0.0 [major release]

[440bx]

My uninformed perspective is that new features are unimportant, but bug fixes are critical.

IMO, the best feature a compiler can have is to be bug free.  No other feature enhances productivity more than that one.

The second best feature is a full implementation of strong type checking (which FPC does NOT implement.)

[ALLIGATOR]

How you can help, even if you don't know much about compiler construction: you can go to the bug tracker and check issues one by one, choosing the ones you like
and write a report stating that the issue has been checked and can or cannot be reproduced at this time
This way, some issues that have long been fixed can be closed, and those that still recur can be updated, perhaps by improving the layout or simplifying the example, or specifying the platforms and operating systems where the error occurs.
While reviewing issues, you can also find related ones and mark each issue with a link to all the others. This helps you check all related issues at once when you close one issue and close them too.

I sometimes do this myself, and some issues have indeed been fixed long ago. I write about this, and then the developers double-check and close what has been confirmed.

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.

I also think that those who still use FPC 3.2.2 and have never used FPC[main] should try it on their code bases. I am not advocating releasing your software on FPC [main] (although I am still convinced that FPC[main] with its bugs is more stable than the ancient FPC3.2.2 with its bugs). I am only suggesting that you help FPC with testing—the more code that is compiled with FPC[main], the faster all the bugs will be found.

[ALLIGATOR]

Early retirement and devoting yourself to developing your favorite language may also help (joke)

[dbannon]

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).

In fact, thats exactly what we see now. Its so long since we had a new release, there are far, far too many new features between fpc 3.2.2 and a mythical 4.0 or even 3.2.4. So, managing that release is a massive, intimidating job. Who would possibly want that job ?

And, the longer it goes on, the harder it gets. The only possible solution I can see is, in fact, a "new feature freeze" on main. Its a pretty normal practice in any large software project. But, possibly too late for even that to work ? I don't know ....

Anyway, "something" must be done, the more new features we get the less likely there will ever be a new release. Thats for sure !

Two (out of millions) examples -

• Debian, a huge (but fragmented) project routinely declares a regular, staged release model, soft freezes, hard freezes, release.  That is the same Debian that has now removed FPC and Lazarus (plus all dependent applications including mine) from its next release.
  
• Lazarus, has a less formal but equally effective release model. About twice a year for minor releases.

Davo

[440bx]

That is the same Debian that has now removed FPC and Lazarus (plus all dependent applications including mine) from its next release.

Just curious, why did they remove FPC and Lazarus from the next release ?

[ccrause]

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.

How you can help, even if you don't know much about compiler construction: you can go to the bug tracker and check issues one by one, choosing the ones you like
and write a report stating that the issue has been checked and can or cannot be reproduced at this time
This way, some issues that have long been fixed can be closed, and those that still recur can be updated, perhaps by improving the layout or simplifying the example, or specifying the platforms and operating systems where the error occurs.
While reviewing issues, you can also find related ones and mark each issue with a link to all the others. This helps you check all related issues at once when you close one issue and close them too.

These are very good ideas.  I would go further and suggest that these activities are best coordinated by a release manager.  It is my uninformed opinion that the core team members are more interested in technical issues rather than project management.  My view of a release manager's duties are:
- Keep track of bugs and categorize bugs as either fixing functionality in a previous release (should go to fixes) or new features (should go to new minor or major version).
- Define release points for fixes (release fixes either after a certain period, or after x number of fixes).
- Possibly define new feature sets for new version.
- Keep track of platform specific issues (a new release should install/run with the default versions of system libraries).
- Coordinate with core developers and regular contributors to focus efforts.
- Possibly also keep an eye on documentation issues, although Michael seems quite effective in this regard.

Yes, possibly an uninspiring list of tasks for a typical coder, but on a project level it is necessary to steer towards a defined goal.

[DrakkTheSeafarer]

I will illustrate here with some simple examples of the unnecessary difficulties we have to overcome daily because of these long intervals between major releases:

For my part, what I find very annoying is that, as an open source project developer, I can only offer projects compiled with the official release of fpc, i.e. fpc 3.2.2, because distros only accept projects that can be compiled with official release versions.

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.

i totally agree with that. most of us are fpc 3.2.2 - long time users. But from my perspective i never understood why the fpc team decided to divide forces and to provide 2 versions of the compiler. The stable version should be polished and nursed to provide a single compiler version that is a reliable and up to date product. Why testing + bugfixing a trunk version that is proposed and never comes.. Maybe a good option would be to spend more effort in bugfixing a single version + make release candidates to introduce new features (slowly). And hopefully this great project will not die!   

[dbannon]

Just curious, why did they remove FPC and Lazarus from the next release ?

The next release of Debian, forky, will not have gtk2. I don't know if that means there will be no gtk2 in the default install or (my guess) not even in the repo. gtk2 is on life support and its about to be turned off.

For historical reasons I guess, there is a gtk2 package in fpc.

Davo

 

[Khrys]

My uninformed perspective is that new features are unimportant, but bug fixes are critical.

This just about sums up where the focus should've been for a while now: we've got loads of new features in trunk (function references & anonymous functions, const generic parameters, custom attributes, the LLVM backend, the WASM backend... the list goes on and on), but the lack of stability prevents any releases from being made.

[plaza1518]

First of all, I would like to apologize if I am wrong, as I am not normally involved in compiler development/maintenance, especially with a compiler like fpc, which has to perform truly “incredible” tasks (platform, CPU, etc.).

Nevertheless, I would like to add my two cents, because I consider the discussion to be very relevant, and FPC is a terrific project in my opinion. Please allow me to elaborate a little:

In my view, there are currently two main problems:

• Long unprocessed open tickets
• Versioning (stable, trunk, etc.)

Compared to other projects I have participated in,  the number of open tickets would “overwhelm” me. Especially since the tickets affect many different developers, which always raises the questions: “How serious is the problem?”, “Does it affect me?”, “Should/must I take care of it?”

In addition, ticket management is also deceptive. Although the problems are recorded in tickets for processing, in reality they are lying somewhere in a basement, and the motto is “out of sight, out of mind” – to put it bluntly.

One suggestion for the topics discussed earlier would be to make these tickets “visible.” FPC already has a functioning and configurable test system. There should be at least one test case for each ticket (associated with the ticket number). These tests should not be blockers under any circumstances. But test runs of these tests would show which problems still exist or which problems have been resolved “by chance” (by fixing other problems).

The respective tickets can be “marked” accordingly, which would be necessary for a ‘stable’ version. And as soon as all currently (!) affected tickets are resolved, a new “stable” version can be defined.

The existence of the other open tickets can be continuously displayed in a list so that FPC users can immediately get an overview of what problems are known that may currently affect them. And as for all currently undiscovered bugs in FPC, there is no need for discussion anyway.

FPC is currently still trying to maintain semantic versioning, but as we can see, this is not working. In reality, semantic versioning no longer exists in FPC in my opinion, but they are sticking to this concept.

Even if some FPC users would like old compiler versions to receive bug fixes for a certain period of time, I believe that this is unrealistic for a project like FPC.

The FPC developers should be realistic enough to face this fact, act/change accordingly, and communicate this appropriately.

[rasberryrabbit]

Optimization level 2 is used in compiler building, but I think it is a problem that the Regvar bug is currently fixed trunk but not official release. There are currently inline bugs that disrupt code generation.

I think it will be easier for future freepascal development if a version with those bugs resolved comes out in the middle.

[440bx]

The next release of Debian, forky, will not have gtk2. I don't know if that means there will be no gtk2 in the default install or (my guess) not even in the repo. gtk2 is on life support and its about to be turned off.

Thank you Davo.  At least their reason sounds reasonable.

[Thaddy]

Just curious, why did they remove FPC and Lazarus from the next release ?

The next release of Debian, forky, will not have gtk2. I don't know if that means there will be no gtk2 in the default install or (my guess) not even in the repo. gtk2 is on life support and its about to be turned off.

For historical reasons I guess, there is a gtk2 package in fpc.

Davo

FreePascal has a GtK2 package, but it is not necessary to use fpc.
Lazarus, however, still uses GTK2 as the default and that won't go with Debian.
I have warned multiple times this would happen and, indeed, it is true.
But that is mainly because of short-sightedness of the Laz devs.
A Qt6 default release would be fine to get it it back in the repo's.

Mind you: Lazarus will disappear from almost ANY Debian derived distro!!!!!!

Thing is: the Debian dev's seem to draw the conclusion that Lazarus is legacy because gtk2 is legacy and that is of course not the case,
but someone has to tell them. The best way to do that is to lead by example and drop gtk2 as default.

[vangli]

Just curious, why did they remove FPC and Lazarus from the next release ?

The next release of Debian, forky, will not have gtk2. I don't know if that means there will be no gtk2 in the default install or (my guess) not even in the repo. gtk2 is on life support and its about to be turned off.

For historical reasons I guess, there is a gtk2 package in fpc.

Davo

FreePascal has a GtK2 package, but it is not necessary to use fpc.
Lazarus, however, still uses GTK2 as the default and that won't go with Debian.
I have warned multiple times this would happen and, indeed, it is true.
But that is mainly because of short-sightedness of the Laz devs.
A Qt6 default release would be fine to get it it back in the repo's.

Mind you: Lazarus will disappear from almost ANY Debian derived distro!!!!!!

Thing is: the Debian dev's seem to draw the conclusion that Lazarus is legacy because gtk2 is legacy and that is of course not the case,
but someone has to tell them. The best way to do that is to lead by example and drop gtk2 as default.

I am not any type of expert. But it is so easy as just to rebuild the IDE selecting Qt6 in 'Tools -> Configure "Build Lazarus ..."? And then you have a Qt6 Lazarus?

I am running Ubuntu 24.04, Lazarus 4.2, FPC 3.2.2 and obvious Qt2 at the moment.

Bent

[Thaddy]

@Bent The standard for Lazarus distro is gtk2. THAT needs to change as quickly as possible.
Now Lazarus is in the pipeline of being removed because gtk2 is removed. That goes for ALL gtk2 dependent software btw.
At most GTK2 should be optional but that needs to ber clear to de Debian dev's
They see GTK2 dependency: --->>>> out with the lot.

For FPC, the gtk < 3 packages should be clearly marked as deprecated. FPC has no dependencies on GTK