We are planning the next release: Lazarus 2.0.8

[Martin_fr]

It is strange that many patches wait for years and are not applied. Why make them at all?

It's a known problem, with many reasons...

Some are simply overlooked.
If no one acknowledged the mantis-report  (in 4 to 8 weeks), then add a ping, or better send a mail to the maillist, asking for the patch to be reviewed.

Some are not picked up, because there is no dedicated maintainer to the code, and everyone is too busy. Or the patch is touching a complex problem, that needs deep investigation and testing. (The "pass the buck" situation / not good, but happens). Same way to go, ask on the mail list.

Once it is assigned, there should hopefully at least be a comment or other communication....

[lucamar]

The intended minimum requirements for the release will be:

Windows:
   2k(*), XP(*), [...]

(*) requires install from sources

Does that means there will be no installer for those two OSs? And, if so, will this be just for this release or from now on?

[JuhaManninen]

Already resolved from the bug list:
34759,

It was a controversial issue and the patch was just applied. I don't feel comfortable merging it. Usually something bad happens with such last moment merges. Also the bug was not serious, no crashes or lost data or such.

35465,

Removing two unused parameters it not a bug fix by any criteria. It can be seen as a useless change because those parameters could be used in some future prospect. I remember getting feedback for applying such a patch.
Anyway, not merging for sure!

35466,

C'mon! Deleting one unused variable is not a bug fix.

35696,

This was applied from Mattias. I marked it for merging anyway now. Thanks.

35173,

Marked for merging now. Thanks.

35512,

Marked for merging. Thanks.

35694,

Minor tweaking, or a micropatch as you call it. Not a bug fix, not merged.

35467.

Another "micropatch" eliminating one variable. Why should it be merged to a bug fix release?

ASerge, I think you have misunderstood the idea of a fixes branch and a bug fix release.
Only bug fixes are merged. No new features, no refactoring, no optimization, no minor tweaking, no controversial patches which will need testing in trunk and possible further changes.

It is strange that many patches wait for years and are not applied. Why make them at all?

Yes but that is a whole different problem. Patches, when applied, are always applied to trunk. Some patches are ignored for a long time which is bad, but it is not related to the process of merging to fixes branch.
Two different things.

[wp]

Already resolved from the bug list:
34759,
35465,
35466,
35696,
35173,
35512,
35694,
35467.
It is strange that many patches wait for years and are not applied. Why make them at all?

I looked through this list and found:
34759 - fixed on May 31, 2020.
35465, 35466,  35696, 35173, 35512, 35694, https://bugs.freepascal.org/view.php?id=35467 - you commented resolved reports. Don't do this, nobody will notice that you added something. Always reopen the report and put it to "feedback" (Not sure if a reporter is allowed to put a report to "feedback". But anyway, even if you can't do this, an unresolved report is much more visible than a resolved one).

[Martin_fr]

Does that means there will be no installer for those two OSs? And, if so, will this be just for this release or from now on?

I am not sure about other recent releases. 

I recently lost an ssd. While I have all my data, all applications/OS had to be re-installed.
The problem is what Windows versions innosetup runs on. The most recent version only targets Vista and up.

I can roll back to the 5.6 version used before, but:
 - not tested, supposedly it supports XP
 - though not sure if that includes the unicode version which was used

Eventually the upgrade will probably be needed, as there may be new features that could be useful.

So if the 2.0.6 installer indeed works on xp/2k (someone needs to test that), and there is demand for such an installer, then we can go for this (and maybe a  few more releases) with the older inno setup.

That said, those older Windows versions are not actively tested. They work, if any bugs are reported in time to be fixed for a release.

[Martin_fr]

Without having gone through the list of bug reports myself (I left a note for the assigned developers), just to note: Usually only fixes (i.e. fix of a bug) will be merged. Features and optimizations will normally not be merged (there may be exceptions, but those are extremely limited)

[sstvmaster]

      Lazarus 2.0.8
      for April 2020 (estimated 14th to 20th)

      This release will be built with FPC 3.0.4.

Does it mean 2.0.8 comes with fpc 3.0.4 or fpc 3.2?

[JuhaManninen]

Does it mean 2.0.8 comes with fpc 3.0.4 or fpc 3.2?

It was written there quite clearly.
BTW, FPC 3.2 does not exist yet.

[Martin_fr]

Does it mean 2.0.8 comes with fpc 3.0.4 or fpc 3.2?

3.0.4

If you want to test with the 3.2RC1 => there are snapshot builds (2.0.7 + 3.2RC1) for Windows: https://sourceforge.net/projects/lazarus-snapshots/
2.0.7 has most of the fixes that will be in 2.0.8.

[JuhaManninen]

- you commented resolved reports. Don't do this, nobody will notice that you added something. Always reopen the report and put it to "feedback"

I noticed when I went through the issues.
Reopening is not needed in this case. Questions about merging etc. is better done in mailing list or here in forum.

[lucamar]

So if the 2.0.6 installer indeed works on xp/2k (someone needs to test that), and there is demand for such an installer, then we can go for this (and maybe a  few more releases) with the older inno setup.

I can confirm that the 2.0.6 installer works in at least: W2K+sp4, XP+sp2 and XP+sp3. I know that those are by now considered "ancient" but there're quite some people out there still using them (on the principle "if it ain't break don't touch it" )

Of course, if there's no other option and we need to do it we'll install from source but having an installer would be a big bonus. Remember that these are rather old machines: building Lazarus on them is quite a lenghty process, more so if one also needs to build FPC (which thankfully isn't the case .. yet?)

[Martin_fr]

Well as long as the Lazarus installer runs, it installs fpc too.

That is of course, fpc must itself be able to run on the machine. As I said, none of this was about the content that gets installed, but only about inno setup running on that machine.

[lucamar]

Well as long as the Lazarus installer runs, it installs fpc too.

Yes; I was thinking more of the future Lazarus 2.2 with FPC 3.2. If there is no installer one would have to install a previous version (say, 2.0.6), build fpc 3.2 and then build lazarus 2.2, which can easily mean a lost morning on an old machine (say a P4 2.4 Mhz w/512 MiB). Yes, I know there are methods to alleviate this (say, copying over an installation from a Win7 machine) but it's still difficult (and slow, though much less) for fully isolated machines.

[Martin_fr]

I've set my scripts back to the older inno setup. I'll see how the build goes, when I build 2.0.8.

I have no immediate plans to change things for 2.2.  So probably going to be ok too.

The Snapshots from 2 or 3 days ago, use the new inno. Further snapshots will be older inno as well. (So there will eventually be builds with the fpc rc that can go onto xp/2k)

[ASerge]

When ready-made patches that are confirmed are not applied for years, it kills the idea of team support for the product, because the work of team members is ignored, citing either lack of time or unimportant completion .