Hello,

I changed the default value for?"Maximize compatibility of project files (LPI and LPS)". Now it is checked (True) for both new projects and existing projects (coming from Lazarus 4.0 and older).

If you use Lazarus from Git main branch, you may see that after a Lazarus update&rebuild, the project files won't be loaded from the LPI. In that case, save the project with empty files and revert the <Unit> lines with your version control system. Keep other changes in the LPI files - especially the added line:
<CompatibilityMode Value="False"/>

Only users?are affected that use and regularly update?Lazarus from Git main branch. Users of stable versions won't have any problems.

---

From now on,?"Maximize compatibility of project files (LPI and LPS)" will always be checked by default. If you want to take advantage of the simplified LPI format and you are aware that your projects won't open in legacy Lazarus versions, you have to manually uncheck it.

Additionally with this change, "Maximize compatibility" now writes not-indexed XML lists. That means that Lazarus 5.0 projects cannot be opened in Lazarus 2.0.x and older even with?"Maximize compatibility" checked.

Ondrej

Sorry this question may be category "dump question". I am trying to catch up ...

What if
-> loading an existing project with version >= 13 would keep the "maximise compatibility" = off. (unless it is explicitly set)

Would that help?
It couldn't happen to any "normal" user, since they can't have that file version.

Maybe that already happens, and I overlooked it, if so => sorry.

People with existing projects with version 13 (from current Git main) and "Maximize compatibility"=False are the only ones affected and have to revert the Unit lines in the LPI how I described it in the first email.

Projects written in version 12 (old Git main or Lazarus 4.0) or version 13 with?"Maximize compatibility"=True are not affected.

Ondrej

Ondrej Pokorny wrote

Additionally with this change, "Maximize compatibility" now writes not- indexed XML lists. That means that Lazarus 5.0 projects cannot be opened in Lazarus 2.0.x and older even with?"Maximize compatibility" checked.

If you can preserve compatibility by writing the indexed XML lists why not keep doing that?

Kostas

https://gitlab.com/freepascal.org/lazarus/lazarus/-/work_items/42423

Lazarus 2.0.x is already more than 7 years old.

Ondrej

Forgive me for not checking myself, but from context I read: Lazarus 3.0 is the first to read the "un-indexed xml list"?

=> Then I would say:? *** Yes ***, 5.0 can scrape the ability to write them. (still needs to read them)

With the exception for basic examples, 5.0 will have so many differences (new LCL functions, different units, new published properties, ...), most projects want load in 2.x anyway.

I would however suggest to change the name of the option, make clear its a different compatibly, e.g. "Write project/package files compatible for Lazarus 3.0"

Not sure about the value for the xml attribute (currently true/false) / maybe change to: "True" (=2.0), "3.0",? ?.... / So we can later know what option the user ticked (in case we ever need to know / maybe we never will)

Martin Frb wrote

Forgive me for not checking myself, but from context I read: Lazarus 3.0 is the first to read the "un-indexed xml list"?

Lazarus 2.2.0 is the first version to support the not-indexed lists.

If you keep your mouse cursor on the checkbox, you get a hint that says: /"Check this if you want to open your project in legacy (2.2 - 4.8) Lazarus versions."/

https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/078e8fa15427f6ba419ffe56958fc136883cbe25

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260719/9e43c2f6/attachment.htm>

<snip>

OK, this got me a bit confused.
Say I have a project with Maximize compatibility of project files (LPI and LPS)". set tot TRUE
This is in a Lazarus main before you made this change (currently my IDE rev main_4_99-4680-g116b31cc32).
The LPI will contain the line:
<CompatibilityMode Value="True"/>
I can open this project in Lazarus main and in Fixes_4

Now I do a git pull and rebuild the IDE.
I open this project in main (that should be no problem as far as I understood). I save the project.
Will I still be able to open the project in Fixes_4?

(Does the line
<CompatibilityMode Value="True"/>
stay in the LPI?)

And will there (in the future) be some global switch to make CompatibilityMode default to FALSE for new projects?

Bart

Yes.

Now I do a git pull and rebuild the IDE. I open this project in main (that should be no problem as far as I understood). I save the project. Will I still be able to open the project in Fixes_4?

Yes.

(Does the line <CompatibilityMode Value="True"/> stay in the LPI?)

Yes, if you open+save it in Lazarus 4.x. Since the default in Lazarus 4.x is False.

No, if you open+save it in Lazarus 5.x then the line will be gone. Since the default in Lazarus 5.x is True. But you will be able to open the project in 4.x because CompatibilityMode=True.

---

If you open a Lazarus 4.x project (even with CompatibilityMode=False) again in Lazarus 5.x, you get automatically forced CompatibilityMode=True back.

And will there (in the future) be some global switch to make CompatibilityMode default to FALSE for new projects?

No, from what I plan.

Speaking from my experience, Lazarus developers are absolutely crazy about backwards and forwards compatibility (see recent discussions). Having CompatibilityMode=True by default is the safest settings. So I assume it will fit most of them as it will cause the least issues in the future.

Advanced users who know the compatibility issues can manually switch?CompatibilityMode to False.

Ondrej

FWIW i do not see this to be the "crazy about backwards" compatibility approach since it does seem to break backwards compatibility without a good reason.

Personally what i'd consider "crazy about backwards compatibility" (let alone "absolutely" :-P) would be to try and keep backwards compatibility for as long as there is a technical solution for it. In this case - especially in this case where AFAICT there isn't much to be gained by doing so aside from saving a few KB on disk (which is pointless in this day and age - or actually was pointless even 30 years ago) and maybe make some diff views easier on the eyes (which again isn't much of a gain because the diffs are still trivial to read with indexed LPIs - and people who really and absolutely cannot stand the extra red/green lines in their diff viewer can disable the maximum compatibility flag).

Of course that is my opinion as someone who is very into backwards compatibility (not sure about crazy though :-P). In practice i guess nowadays you can throw some a pair of new and old LPI files in an LLM and ask it to write a Python script to convert one to the format of the other and you'll probably get something working in a manner of minutes.

Kostas

Maybe you mixed up backwards and forwards compatibility? Backwards compatibility is "open old files in new program versions" and obviously is a?a no-brainer for the LPI files.

The "CompatibilityMode" is about forwards compatibility (open new files in legacy program versions).

Absolutely no backwards compatibility is broken with the LPI file change.

Ondrej

Ondrej Pokorny wrote

Maybe you mixed up backwards and forwards compatibility? Backwards compatibility is "open old files in new program versions" and obviously is a?a no-brainer for the LPI files.

Backwards compatibility is also being compatible with old stuff in general. So selecting a "backwards compatible file format" would make sense when it comes to being compatible with older versions.

Wikipedia's article actually puts it nicely:

"In telecommunications and computing, backward compatibility (or backwards compatibility) is a property of an operating system, software, real-world product, or technology that allows for interoperability with an older legacy system, or with input designed for such a system."

In this case, new Lazarus being able to create LPI files compatible with old Lazarus would fall under "allows for interoperability with an older legacy system".

What you describe is the second part, "or with input designed for such a system" (in this case an LPI file that uses the old format is the "input designed for such a system" - i.e. input for an old version of Lazarus).

Forward compatibility is about future stuff (mainly making sure that future versions can preserve backwards compatibility), so they're not relevant to what i wrote.

Kostas

https://en.wikipedia.org/wiki/Forward_compatibility

I am not going to discuss what you understand under backward/forward compatibility. It's not relevant.

Ondrej

Ondrej Pokorny wrote

https://en.wikipedia.org/wiki/Forward_compatibility I am not going to discuss what you understand under backward/forward compatibility. It's not relevant.

The forward compatibility aspect is indeed irrelevant. This matches with the Wikipedia link you provided:

"Forward compatibility or upward compatibility is a design characteristic that allows a system to accept input intended for a later version of itself." <-- this is another way to write what i wrote "mainly making sure that future versions can preserve backwards compatibility".

It is also, "not relevant to what i wrote", as i already wrote in the email you responded.

In my original mail i focused on the backwards compatibility aspect (specifically new versions of the Lazarus LPI format being compatible with older version of Lazarus) which is not irrelevant as the LPI change breaks one aspect of backwards compatibility ("interoperability with an older legacy system" as Wikipedia puts it).

Also FWIW i'm not trying to argue against the change or anything like that, i'm only pointing out that this isn't being "crazy about backwards compatibility", which was what triggered my response. It was meant to be taken as a comment in a "this is far from crazy, you can be much crazier than that" sort of manner :-).

Kostas

That's exactly what I broke. Lazarus 2.0.x is not able to to accept input intended for Lazarus 5.0 (later version of itself). So?Lazarus 2.0.x is not forward compatible with Lazarus 5.0 anymore.

The general rule for forward compatibility in Lazarus is one newer stable version. That means that a particular Lazarus should be able to open and work with files from the stable version right behind it (4.8 -> 5.0). But usually this forward compatibility spans over more versions.

There is no "interoperability" between different Lazarus versions, Lazarus programs do not talk to or interact with each other - this statement applies more on telecommunications, API and other protocols.

You should rather read the "In software" chapter:
https://en.wikipedia.org/wiki/Backward_compatibility#In_software

/In compilers, backward compatibility may refer to the ability of a compiler for a newer version of the language to accept source code of programs or data that worked under the previous version./

/A data format is said to be backward compatible when a newer version of the program can open it without errors just like its predecessor./

Lazarus 5.0 reads all older LPI formats correctly - it is backward compatible.

Lazarus 2.0.x doesn't read LPI from 5.0 - Lazarus 2.0.x is not forward compatible with Lazarus 5.0.

*Backward compatibility is not about being able to save files in a legacy format.* That is the "Legacy mode":
https://en.wikipedia.org/wiki/Legacy_mode
And that is exactly what we have in Lazarus for the LPI format (we call it "Compatibility mode").

/In computing, legacy mode is a state in which a computer system, component, or application software behaves in a way that is different from its standard operation in order to support older software, data, or expected behavior. It differs from backward compatibility in that an item in legacy mode will often sacrifice newer features or performance [...]/

The "Legacy mode" in Lazarus 5.0 allows you to write LPI for Lazarus 2.2-4.8. In 5.0 I removed "Legacy mode" support for Lazarus 2.0.x and older. *I did not brake backward compatibility.*

I even made the "Legacy mode" default.

...

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20260722/31c7f805/attachment-0001.htm>

Ondrej Pokorny wrote

...

I'm not sure how to interpret this TBH. In my last email i tried to be amicable, explaining the thought process that made me write the mail before that.

Anyway, let's go with the classic "agree to disagree" when it comes to those terms - i was typing a much larger response but i decided to delete it as don't think it'd be constructive.

The only worthwhile part - if anything - from my previous mails is that i think there isn't really a technical reason why Lazarus should break compatibility with old Lazarus versions (regardless of how old they are) when there are technical means of doing so, but beyond that i don't think it is a big deal as there are still ways for people who want to develop something using the latest Lazarus to make it work with an old Lazarus if they want to.

Kostas