FPC 3.2.4-rc1 available

[JuhaManninen]

Basically: one never commits to a RC unless approved by a release manager and done with his/hers permission or by him/herself. Even if you a core developer. Basic rule number one.

That rule may be good in a commercial environment where a project's timeline and new features are strictly administered and well defined tasks are delegated to certain developers.
It is not a good rule in an open source project where everybody scratches his own itch and there is no top-down design nor administrative hierarchy.
In our open source projects the developer knows best if his commit is a bug fix or not.
Yes, a commit should first be tested in trunk for some time but that also is flexible. A fix for a clear AV or memory leak typically does not need long testing.
What would happen if I had to decide which commits from Zeljko's GTK3 improvements should be merged? Or from Martin's debugger improvements? It would be guess-work.
The current process is light and has minimal overhead. If there is a merge conflict, I typically leave the commit out. It will be in the next major release which happens frequently enough so it is not a problem. Everybody is happy and time is saved for real productive tasks!

[Thaddy]

That is not how I perceive current and historic practice for the releases: it seems the theory is followed pretty close. At least up until now and for the compiler itself.

[marcov]

That is not how I perceive current and historic practice for the releases: it seems the theory is followed pretty close. At least up until now and for the compiler itself.

Juha doesn't seem to read any counter messages.  Anyway, even if you believe his oversimplifications, he himself says that first major releases need to be accelerated before you use that in a policy for minor releases. That's the whole cart-before-the-horse problem of the current discussion. It raves about main-> fixes, but says nothing about rotating main to fixes. 

And while we can ignore the compiler and attached RTL( since they are complex, but are rarely merged to fixes now either), but the time also gives time to run a CI on umpteen platforms, including ones that are not part of a single centralized buildfarm (and e.g. have lower frequency).

But anyway, the writing is on the wall. We go back to high tech version of pre 2.2.2 times, where releases are done without actually making an effort to have anything in them. The maintainer concludes that the committers haven't flagged anything(not flagging for merge out of caution, and then promptly forgetting about it), triggers the build, and the timed released is executed on schedule. (but essentially the same as the last, except for some high profile fixes).

In the past, except the obvious delay of fixes reaching releases, that caused a whole lot of untested code to reach users only with the x.y.0 release, which was then promptly skipped by everybody, including Lazarus. However much more people nowadays use/test main, so it is not exactly the same situation. Back then only core + a few regular contributors used trunk/main.

[dbannon]

.... It changes the goal of the release manager of finding things to merge to make the release as good as possible, to what is spoon fed by the developers.

Yes, it does. After all the developer is the one who understands what the patch is for and how it works.

Debian is primarily a packaging project, not a software development process. They simply package something old and stable if a new release is not available.

Well, maybe. But they also manage an avalanche of requests from app developers (like me) who want to get the latest version into the next release. And they manage the conflicts and incompatibility that inevitably crop up.

I guess my point is, the current system is apparently not working. We can keep doing the same thing, expect the same result. Or consider change. Fortunately, its not up to me to choose.

Davo

[marcov]

I guess my point is, the current system is apparently not working. We can keep doing the same thing, expect the same result. Or consider change. Fortunately, its not up to me to choose.

That is my whole point. That is just not true. It is not executed, so how could you know if it works?  With whatever system, if no work is done, nothing happens. Are therefore all systems bad? No.

The current process worked fine for more than a decade, and there is nothing fundamentally wrong with it that it could not support 2 fixes releases per year. With the original care and everything.


I still think Debian is a bad match for comparisons. But obviously they have more workers interested in releasing. That is the difference, not the process.

[440bx]

The current process worked fine for more than a decade, and there is nothing fundamentally wrong with it that it could not support 2 fixes releases per year. With the original care and everything.

Wait... from what I've understood, the current process isn't the same as the previous process, specifically, the software used to manage the releases isn't the same and the release manager also isn't the same.

Those changes likely imply other changes in the process that are not obvious but there nonetheless.  We all see the result: 5 years without a release and I believe that's what we all want to avoid in the future.

I think @Juha has a point.  FPC is a large and varied project.  Even someone who is very well versed in compiler development is unlikely to be an expert in every platform FPC supports, including the different code generators, optimizers and linkers required for different platforms.  This implies that whoever is managing the global project has to delegate responsibilities to other members to ensure those parts of the project keep advancing and make it into the next release in a timely basis.

Quite likely my perception is overly simple but, it seems to me that, at this point, the current release manager is part of the problem.

[robert rozee]

[...] much more people nowadays use/test main [...] [whereas in the past] only core + a few regular contributors used trunk/main.

on what evidence do you base the assertion that "much more people nowadays use/test main". the Lazarus website links to SourceForge for downloads, where FPC 3.2.2 is the most recent version hosted. likewise, freepascal.org provides links only (as far as i could see) to FPC 3.2.2.

according to google, "As of early 2026, the Lazarus IDE has well over four million total downloads from SourceForge", while regarding FPC, google says that, "SourceForge frequently highlights that the [FPC] project has exceeded over 100,000 total downloads".

the above suggests to me that:
1. FPC is far more often used with Lazarus than on its own, and,
2. of the folks using FPC (with or without Lazarus), the vast majority are using FPC 3.2.2.


do you have any concrete numbers for how many people use test/main/trunk?


cheers,
rob   :-)

[marcov]

The current process worked fine for more than a decade, and there is nothing fundamentally wrong with it that it could not support 2 fixes releases per year. With the original care and everything.

Wait... from what I've understood, the current process isn't the same as the previous process, specifically, the software used to manage the releases isn't the same and the release manager also isn't the same.

This cycle had to adjust to GIT, and that caused many delays, but the essence remains the same. But the migration could also have been handled much faster. And there was no reason to hold the fixes branch over an year in freeze if you don't initiate anything to make a final release.

Those changes likely imply other changes in the process that are not obvious but there nonetheless.  We all see the result: 5 years without a release and I believe that's what we all want to avoid in the future.

If you really want to see the cause in the process no matter what yes. But I'm telling you, that is not it. It is the people. They get older, have less free time, and prefer to spend time on fun things rather than thinking of releases.  The new release manager avoids conflict, so didn't force people to do their thing now, or forget about it,  and presto, a 5 year gap.

I think @Juha has a point.  FPC is a large and varied project.  Even someone who is very well versed in compiler development is unlikely to be an expert in every platform FPC supports, including the different code generators, optimizers and linkers required for different platforms. 

As said, the compiler is not merged via common procedures anyway after the .0 release. Between branching a new fixes branch and the .0 release, there is a lot of main-> fixes merging that is relatively straightforward, but after that less and less, as simply the class/datastructure of the compiler changes, needing a real will to migrate changes.

This implies that whoever is managing the global project has to delegate responsibilities to other members to ensure those parts of the project keep advancing and make it into the next release in a timely basis.

Delegating also means following up if that doesn't happen, and having process in place for that. And that is where the problems of such approach lie.  In companies and high profile open source project with dedicated release people and/or even paid workers that simply means rotate to the next grunt to do the work and a negative recommendation.

What do you do in the future if a committer hardly merges up front, and if you talk to him about it he says "safety" and says he will look at it the weekend after next ?  Read all the mails of Michael and Graeme c.s., and see what alternate procedures they describe except for the "flag for merge at the moment" and the "release manager that dutifully and automatically presses the button when prompted". They don't even commit to maintaining an eligible revision list, making falling back to the current process in the case of problems, or simply to mop up revisions that were wrong.

Sometimes when asked, they all postpone that to the future and scripting and the like. Just like they did with the gitlab migration, but it took over 1.5 years to get basic cherry-picking with a list of merged revisions available. By the time such things are sorted, the new fixes branch will already be old.  And even if the support still must be written, you could outline things way more detailed.

Quite likely my perception is overly simple but, it seems to me that, at this point, the current release manager is part of the problem.

Certainly. But it is carrying out the tasks, not the tasklist that is the problem.

[marcov]

do you have any concrete numbers for how many people use test/main/trunk?

Just my gut feeling from anecdotal evidence on maillist and bugtrackers.  Most relevant users that submit detailed bugreports and the like won't use a pre built snapshot, as they would require a FPC compiled with debuginfo.   To debug, and get traces etc.

No Lazarus build provides that at the moment. Rightfully so, because such builds are a pain to use daily, tracing into any language helper. Lazarus could help by doing what Delphi does, having a tree with and without debuginfo, and maybe even more gradations inbetween (like anything but system/objpas/sysutils/classes without debugging).

I talked to MartinFr about it, and he is working on a system to let the debugger only enter a function/procedure if the unit is on a list, but that will take a while.

[440bx]

@marcov, thank you for the details.

[Martin_fr]

I talked to MartinFr about it, and he is working on a system to let the debugger only enter a function/procedure if the unit is on a list, but that will take a while.

Actually that is in 4.99. (mainly for FpDebug, but in limited versions also gdb and lldb).  It works great for all the fpc_check_object, fpc_ansi_assign, ....

It is NOT based on packages though. You need the names of the function or files. (IIRC, at least fpdebug sees the full path, so you could use parts of the path / but don't recall if I tested that). (that is a once off, 2nd time you change between debug and release compiler will be handled by the IDE)

And the IDE 4.99 now also deals with the wrong full path of a pre-build debug FPC. It just requires the user to do a manual rebuild of his project (and LCL/etc packages), or it will fail "ppu changed".

[dbannon]

I still think Debian is a bad match for comparisons. But obviously they have more workers interested in releasing. That is the difference, not the process.

Yes. The process is not happening simply because key people do not see it as a high enough priority.

Thanks Marcov, I think we understand now.

Davo

[marcov]

Yes. The process is not happening simply because key people do not see it as a high enough priority.

Thanks Marcov, I think we understand now.

And force through major changes without either being ready, or having contingencies. See e.g. last comment of Michael https://gitlab.com/freepascal.org/fpc/source/-/work_items/41735

Basically they are going to ruin the eligible version registration in a last ditch effort.

[Thaddy]

@Marcov

As long as the tests pass, that is.
I would do the same...

Then it is a second to last ditch.

Btw, my debug builds are also not daily, but current is, so I am cheating myself, I know. I do a debug build only when I am out of wit.

[Thausand]

Basically they are going to ruin the eligible version registration in a last ditch effort.

I not understand why you have write this and other message again.. again ... again... for people not know please have read all discussion not state only opinion and not have real answer.

If want opinion, then I make also: If some one is think I make spend more time motivate why my work is need for eligible after > 4 year then better have think again. That is why exist commit message -> so take time and read what is motivate.