Rolling releases Lazarus[stable or main]+FPC[main]

[Martin_fr]

My opinion: I guess it does not need to be optional if it is anonymous or at least enabled by default.

I have my doubts that this is going to happen. IIRC (but its rather a good bit down memory lane) there was a discussion about the online package manager, and the result was that it should - by default - not check online. The user has to enable that first.

So adding a "send stats home", and have it on by default? Seems unlikely.

What can it help:
Like many projects it helps knowing what users want or use and focus on that. I know people talk on forum but we know what people say and what the act is different.
It can help advertise the project and give more confidence to the developers and users. You know the old repeated saying of no one is using Pascal.
It helps with knowing what versions are used and advertising updates, reducing the pressure of keeping old versions around. Less pressure for the team.
And it all helps some people more motivated to work on a project that feels more alive.

It feels alive to me. Taking
- the numbers from Sourceforge for Windows
- Linux is likely under-represented, since the distros have their own repos
- The FpcUpdeluxe thread has a lot of posts, so I would think lots of people use it

As for "being alive", imho the Sourceforge numbers do certify that.

As for keeping Old versions around: On the Lazarus site we don't really do that. We have one release branch that we work support. (Well we keep it possible to compile with the previous FPC, currently that is 3.2.0 and 3.2.2 as well as fixes and trunk)

As for what features to concentrate on.... I don't know the other team members, but for my work there are a lot of other factors than, what would be the most wanted. Also there would be a huge difference between what is used, wanted and needed.
I.e. if feature Foo is most used => then that just means: its available and known. So that means we don't need to care for Foo anymore? Or we need to care especially for it?
So should we start advertising other available features, or concentrate on the known ones?
If it is others, then which? That info isn't part of current usage.

There would be the option to advertise the numbers that we have. Version 3 had 120000 Windows downloads on SF => I would say, with all other downloads that would indicate at least a quarter of a million users, maybe more (there are lots of people who either are blocked by sourceforge, or don't use it due to past bad press / so lots of people that would use other downloads).

That said, I am not in the business of advertising. Someone else has to pick that up.
Actually waiting for volunteers on that for a long time....  The team is made from software developers (naturally), so marketing experts are missing.
Anyone can write and publish reviews. Including contacting media outlets, and provide them with articles they can publish. Well, at least there is a bit of activity now with various youtube channels. That is at least some advertisement.

But IMHO, that is the more important part. People with marketing and presentation skills to present the project.

As far as I know FPK is the the lead maintainer for FPC, and Sven is the active representative. Are there such persons for Lazarus? I know your work on everything about the IDE especially the debugger, but I like to know if there is a team structure. For example how do you decide to have rolling release for example.

We don't really have a "one leader".

Different team members maintain different parts. For all else, we discuss some of the more general directions on a private mail list. But often the main criteria is, if someone wants to do the work at all (and has the time...).

[rasberryrabbit]

I have fpc main/lazarus main custom build by fpcdeluxe. Main compiler is i386-win32, it can use x86_64-win64 cross compiler.
Some packages and units. It archived 900+MB size and it need 4GB free space on disk.

It contains some MR and bug fixes.
There is tool "fpcupset.exe" for setting up environment configuration for lazarus.

Enjoy it. 

fpc / lazarus ~ 900+MB, 31 january, include fix for #41353, #41598, #41599, #41564 , #41591 (Run fpcupset to setting path.)
https://transfer.it/t/vFDzJNwDQTrb

fpc only(binary, source) ~125MB, 31 january, include fix for #41353, #41598, #41599, #41564, #41591  (It need change path on fpc.cfg file manually.)
https://transfer.it/t/wdP28R5X2DoI

[JuhaManninen]

I wonder where you got the idea that new features are the problem with fixes release. 

It must be one reason. New merged features can bring new bugs and require vigorous testing again. Pure bug fixes have only a small chance to introduce new bugs.
Thus a testing period for a dot-release with only bug fixes is shorter.

One reason often given is that building the release for all various platforms is laborious and all platforms don't even have a maintainer with proper hardware any more.
The solution would be a source code release with built binaries for only Windows and maybe MacOS (I don't how important the binaries are for Mac users).
It basically means tags in revision control and announcements in forums, web pages and elsewhere. A testing period before release is needed of course but if some exotic platform does not have a maintained, tough luck, but it should not kill a release from all major platforms.
Linux, BSD etc. distros build their own installation packages anyway for their repositories. They don't need binaries from FPC project.

Thus the release effort for a dot-release with only bug fixes would be light and easy.

[valdir.marcos]

... For example how do you decide to have rolling release for example.

Lazarus releases are rolling quite nicely already, meaning they are released reasonably often. The testing period for a "release candidate" is rather short, too, not prolonged artificially.
FPC release cycle is the problem. Lazarus release must use a released FPC. So do Linux etc. distros.
There are fundamental flaws in FPC release process. For example a minor dot-release should contain only bug fixes and they should be released often. FPC decided to add new features there, too. So we are still waiting for a dot-release for year after year after year ...
The situation is so bad I hope somebody forks the project and starts to maintain releases. I guess bug fixes would start to flow to the new better maintained project, too.
The current situation makes FPC look dead from outside which doesn't really matter. What matters, it makes life more difficult for people who use it and don't see it as dead.
The explanation is always "it will be released when it is ready" which is dummy because no substantial SW will ever be ready. That's why multiple release versions are made.

I am very grateful for your understanding of our daily suffering over the last 6 years.

There is a lot of useful new [stable enough] content in the Trunk that we are forced to extract haphazardly to remedy our needs. This happens because a major release takes 6 years or more to be released.

There are also many small fixes that we don't have easy access to because a minor version takes many years to be released. This also forces us to manage a multitude of manual patches on our systems.

All of this happens because of incomprehensible decisions in the chain of command within the FPC team. The leadership of the FPC should be rotated from time to time so that other people can bring new ideas.

[PascalDragon]

As far as I know FPK is the the lead maintainer for FPC, and Sven is the active representative.

I'm not the active representative, there are also others.

I wonder where you got the idea that new features are the problem with fixes release. 

I must be one reason. New merged features can bring new bugs and require vigorous testing again. Pure bug fixes have only a small chance to introduce new bugs.
Thus a testing period for a dot-release with only bug fixes is shorter.

Again, it's not features (of which there are none) that are the issue, it's the release management itself. Mainly because we still have issues with the migration to Git and we also have a new release manager (namely fpk instead of marcov).

[valdir.marcos]

There are fundamental flaws in FPC release process. For example a minor dot-release should contain only bug fixes and they should be released often. FPC decided to add new features there, too. So we are still waiting for a dot-release for year after year after year ...

I wonder where you got the idea that new features are the problem with fixes release. 

The situation is so bad I hope somebody forks the project and starts to maintain releases. I guess bug fixes would start to flow to the new better maintained project, too.

Wishful thinking, and not realistic at all.

The current situation makes FPC look dead from outside which doesn't really matter. What matters, it makes life more difficult for people who use it and don't see it as dead.
The explanation is always "it will be released when it is ready" which is dummy because no substantial SW will ever be ready. That's why multiple release versions are made.

If you don't consider that release management to be doing anything for a stable product, simply use a snapshot.

Wishful thinking, and not realistic at all.

[PascalDragon]

If you don't consider that release management to be doing anything for a stable product, simply use a snapshot.

Wishful thinking, and not realistic at all.

marcov is right: If someone does not think that release management does anything for providing a stable product, than one can just as well use a snapshot.

[valdir.marcos]

I wonder where you got the idea that new features are the problem with fixes release. 

I must be one reason. New merged features can bring new bugs and require vigorous testing again. Pure bug fixes have only a small chance to introduce new bugs.
Thus a testing period for a dot-release with only bug fixes is shorter.

One reason often given is that building the release for all various platforms is laborious and all platforms don't even have a maintainer with proper hardware any more.
The solution would be a source code release with built binaries for only Windows and maybe MacOS (I don't how important the binaries are for Mac users).
It basically means tags in revision control and announcements in forums, web pages and elsewhere. A testing period before release is needed of course but if some exotic platform does not have a maintained, tough luck, but it should not kill a release from all major platforms.
Linux, BSD etc. distros build their own installation packages anyway for their repositories. They don't need binaries from FPC project.

Thus the release effort for a dot-release with only bug fixes would be light and easy.

I tend to agree with you.

And I would add that short development cycles are better than long ones:

A major release every 2 years, containing ONLY new features that are stable enough. [Obviously, the rest would be for the next cycle].

A minor release every 6 months, containing ONLY new bug fixes that are stable enough. [Obviously, the rest would be for the next cycle].

[valdir.marcos]

If you don't consider that release management to be doing anything for a stable product, simply use a snapshot.

Wishful thinking, and not realistic at all.

marcov is right: If someone does not think that release management does anything for providing a stable product, than one can just as well use a snapshot.

I respect your work and opinion, but read below:

True, but the point is that in trunk there can (at times) be more. And that is not just a theoretical issue.

Right now, I would recommend 3.2.3.  Chances (extremely high) are that the number of fixed compiler bugs (several, compared to 3.2.2) outnumber any potential new ones (and given its a fixes branch, new ones are possible but less likely).

But that aside, trunk is a gamble.

[Martin_fr]

I respect your work and opinion, but read below:

Right now, I would recommend 3.2.3.  Chances (extremely high) are that the number of fixed compiler bugs (several, compared to 3.2.2) outnumber any potential new ones (and given its a fixes branch, new ones are possible but less likely).

But that aside, trunk is a gamble.

While I do stand by my recommendation, I don't mean to invalidate the need of proper release preparation.

An overall reduction of bugs, even most drastic reduction, may mean an overall higher quality, and an improvement for many people.

But, a single tiny overlooked regression can still be very bad news for "someone". I.e. someone releasing their product tested and adapted to the current issues could be bitten badly by that one tiny regression.
To me, that isn't a reason to withhold my recommendation.
A person in such a need of non-regression should be aware of their situation, and know that my recommendation is not the same as a release. A release still isn't a guarantee, but at least an additional effort to supply for that need.


And well, I have no insight into what the reasons for the hold ups are. But I also feel that it really needs to get moving (again).

My opinion:
If there are individual platform/targets that can not progress (for whatever reason there may be), then exclude them, remove them from supported, add them again if and when the issues are solved. If they block everything, then those targets are not released. If they are temp removed, then its exactly the same. And if they can be provided again, then they will be back (just as they would be if everything is blocked).

I know its GIT now, no longer SVN. But my understanding is that FPK has truly excellent git knowledge. Obviously he knows the compiler too. And I would be surprised if that wouldn't extend to the rest of the toolchain.
The release process itself may have its pitfalls. Though if it worked for the RC, then the steps should be repeatable.
I obviously don't know about available time, that is a factor hard to control.

Whatever it is, if it can't be solved within just the team, document it and see if anyone can step up to help.

[marcov]

I wonder where you got the idea that new features are the problem with fixes release. 

I must be one reason. New merged features can bring new bugs and require vigorous testing again. Pure bug fixes have only a small chance to introduce new bugs.
Thus a testing period for a dot-release with only bug fixes is shorter.

Any "new features" (and I use that term loosely) are mostly RTL and packages, which are less sensitive than the compiler. Most are even additions and not changes, unlikely to introduce bugs.

The compiler is where the blocker bugs usually are. (for both 3.2.0 and 3.2.2 e.g. it was the currency support on 64-bit)

One reason often given is that building the release for all various platforms is laborious and all platforms don't even have a maintainer with proper hardware any more.

This notion is outdated, since 3.2.2 the release will go on if Tier 1 targets (say 64-bit linux,  Windows and OS X) are uploaded. Even before there was a more informal agreement about not every last target.
Most building takes a week, occasionally OS X or iOS take longer because the annual new versions have a tendency to break things.

The overall slowdowns are not related to building but are more about getting a list of must fix issues on the table, and getting them actually fixed.

The solution would be a source code release with built binaries for only Windows and maybe MacOS (I don't how important the binaries are for Mac users).

The building is not the issue. If there are problems, it is the problems discovered during building, so releasing only source only releases a unbuildable product. But with some exceptions (like a new OS X version in the months before a release that breaks everything) those are not the biggest problem.

It basically means tags in revision control and announcements in forums, web pages and elsewhere. A testing period before release is needed of course but if some exotic platform does not have a maintained, tough luck, but it should not kill a release from all major platforms.

Linux, BSD etc. distros build their own installation packages anyway for their repositories. They don't need binaries from FPC project.

Thus the release effort for a dot-release with only bug fixes would be light and easy.

This is pure phantasy, and not rooted in any fact.

Anyway the core issues for a fixes release are (assuming a functioning release manager):

• The notion that release/branch management only needs to be done during release periods, and not continuous. This is the biggest problem, getting people actually in some form of release mode.
• Making/maintaining a list of current remaining issues and their status.
• Getting them fixed

The core problems are not related to

• tooling. It can be always be improved. But IMHO you can better spend time getting bugs covered in the testsuite than implementing wild ideas.
• minor targets. They were never blocking, at worst it would delay a release by a week if a maintainer thought he could make it. It is not related to 4-5 year release gaps

Later releases (say after 3.0) the blockers on the must fix issues list became increasingly compiler related. The direct reason why I gave up being the release manager was git related (I had to start with git from scratch, and when the git migration was forced through there was no tooling to maintain the fixes branch). But there were other reasons too, and I felt a compiler developer as release manager would navigate the increased importance of blocking bugs in the compiler better/faster.

Major releases are even more compiler centric wrt to the blocker bugs.  Bug fixing is the main bottleneck with 1-2 years doing that between branching and release in recent times, and more complicated features like generics, unit system rewrites, and for 3.2.0 SEH on 32-bit makes that much slower. Developers need time to pinpoint and find complex bugs.

The blocker list is nearly 100%  compiler related, so for a major releases, having a compiler developer as release manager will be even more important.

[dsiders]

I wonder where you got the idea that new features are the problem with fixes release. 

I must be one reason. New merged features can bring new bugs and require vigorous testing again. Pure bug fixes have only a small chance to introduce new bugs.
Thus a testing period for a dot-release with only bug fixes is shorter.

Any "new features" (and I use that term loosely) are mostly RTL and packages, which are less sensitive than the compiler. Most are even additions and not changes, unlikely to introduce bugs.

The compiler is where the blocker bugs usually are. (for both 3.2.0 and 3.2.2 e.g. it was the currency support on 64-bit)

One reason often given is that building the release for all various platforms is laborious and all platforms don't even have a maintainer with proper hardware any more.

This notion is outdated, since 3.2.2 the release will go on if Tier 1 targets (say 64-bit linux,  Windows and OS X) are uploaded. Even before there was a more informal agreement about not every last target.
Most building takes a week, occasionally OS X or iOS take longer because the annual new versions have a tendency to break things.

The overall slowdowns are not related to building but are more about getting a list of must fix issues on the table, and getting them actually fixed.

The solution would be a source code release with built binaries for only Windows and maybe MacOS (I don't how important the binaries are for Mac users).

The building is not the issue. If there are problems, it is the problems discovered during building, so releasing only source only releases a unbuildable product. But with some exceptions (like a new OS X version in the months before a release that breaks everything) those are not the biggest problem.

It basically means tags in revision control and announcements in forums, web pages and elsewhere. A testing period before release is needed of course but if some exotic platform does not have a maintained, tough luck, but it should not kill a release from all major platforms.

Linux, BSD etc. distros build their own installation packages anyway for their repositories. They don't need binaries from FPC project.

Thus the release effort for a dot-release with only bug fixes would be light and easy.

This is pure phantasy, and not rooted in any fact.

Anyway the core issues for a fixes release are (assuming a functioning release manager):

• The notion that release/branch management only needs to be done during release periods, and not continuous. This is the biggest problem, getting people actually in some form of release mode.
• Making/maintaining a list of current remaining issues and their status.
• Getting them fixed

The core problems are not related to

• tooling. It can be always be improved. But IMHO you can better spend time getting bugs covered in the testsuite than implementing wild ideas.
• minor targets. They were never blocking, at worst it would delay a release by a week if a maintainer thought he could make it. It is not related to 4-5 year release gaps

Later releases (say after 3.0) the blockers on the must fix issues list became increasingly compiler related. The direct reason why I gave up being the release manager was git related (I had to start with git from scratch, and when the git migration was forced through there was no tooling to maintain the fixes branch). But there were other reasons too, and I felt a compiler developer as release manager would navigate the increased importance of blocking bugs in the compiler better/faster.

Major releases are even more compiler centric wrt to the blocker bugs.  Bug fixing is the main bottleneck with 1-2 years doing that between branching and release in recent times, and more complicated features like generics, unit system rewrites, and for 3.2.0 SEH on 32-bit makes that much slower. Developers need time to pinpoint and find complex bugs.

The blocker list is nearly 100%  compiler related, so for a major releases, having a compiler developer as release manager will be even more important.

Thank you for your candid and detailed response.

I now feel a little less like a mushroom...

[rasberryrabbit]

https://gitlab.com/freepascal.org/fpc/source/-/issues/41353 open -> mulx unsigned multiply instruction used on signed integer. I upload patch.
https://gitlab.com/freepascal.org/fpc/source/-/issues/41431 open -> same as 40291. If parameter is written, it allocated temp var when inlined. I recenly update patch for it.

Yes, of course.

Going through my recent reports, the following are code-generator issues
https://gitlab.com/freepascal.org/fpc/source/-/issues/41466 fixed in the meantime
https://gitlab.com/freepascal.org/fpc/source/-/issues/41431 open
https://gitlab.com/freepascal.org/fpc/source/-/issues/41422 open
https://gitlab.com/freepascal.org/fpc/source/-/issues/41353 open

The 2nd one (inline) turned out to already had a prior report (and for quite some time already). But by the time I found enough info to report it, I did then forget to check.

And I must say, for something that fundamental (IMHO) as inlining, I was surprised to find that its been known for so long.
That said, I know it happens... I have bugs on my list, that ought to have been fixed very long ago, and yet haven't been.

[JuhaManninen]

OK then.
A suggestion: release FPC 3.2.4 now. It is much better already even with the remaining bugs. Then you can fix more bugs and release FPC 3.2.6 after 6 months.
That's how it should go.

[ALLIGATOR]

OK then.
A suggestion: release FPC 3.2.4 now. It is much better already even with the remaining bugs. Then you can fix more bugs and release FPC 3.2.6 after 6 months.
That's how it should go.

👍🥳

Any movement will 💪invigorate💪 the community