I finally changed the XML format for Lazarus projects. It means the list of units and buildmodes etc.
The format was not ideal because adding or removing an item resulted a big diff and potential merge problems.
See this report for details:
https://bugs.freepascal.org/view.php?id=22752
The patch is by Ondrej.
Please test with Lazarus trunk r60683.

Regards,
Juha

Yes !!! Finally !

Many thanks to you and Ondrej =-)

Michael.

Great.

Sadly, it fails with some tools and I have to open projects in Lazarus 2.0. Is it possible to store some projects in the old format?

Mattias

Found it. Nice.

Mattias

PM Mattias Gaertner wrote

Sadly, it fails with some tools and I have to open projects in Lazarus 2.0. Is it possible to store some projects in the old format?

Yes, there is option :
Maximize compatibility of project files (LPI and LPS) in Project Options -> Miscellaneous.
I did not test the option much myself. I guess it will get tested now by you and many others. It is a typical use case after all.

Juha

Great, thanks. I hope that old files will be read ok and then saved to new format.

PM Alexey wrote

Great, thanks. I hope that old files will be read ok and then saved to new format.

I hope so, too. :)

Juha

I think we have a big mess now. This option must be ON at least until the release of the next version. The way it is now the current release version cannot read any project modified by trunk.

And what happens when the next release appears? We will have the same situation. This way the new format can never be introduced without breaking the current release version unless the information is written in some kind of duplicate way: The old version always reads the old nodes if new nodes are not available, or the new nodes otherwise, the new version writes both old and new nodes when the compatibility option is ON. Later, a few versions in the future, when all old nodes have been replaced by new nodes we can switch the default of compatibility option to OFF.

PM Werner Pamler wrote

I think we have a big mess now. This option must be ON at least until the release of the next version. The way it is now the current release version cannot read any project modified by trunk.

That is perfectly OK because there is the option. You can turn it on with just one mouse click.
Changing the default value in code ON/OFF would pollute the local config file without any real benefit.
Most people just use the latest release version.
Some others, including myself, use only trunk. If I need to test the last release version, then I will use the option.
Mattias and you apparently need the option. What is the problem? No mess IMO.

Juha

Juha Manninen wrote

What is the problem?

Suppose I fix a bug in a demo program which comes with Lazarus, it clearly is a bug and there is no reason why it should not be backported to Fixes. I usually work with trunk, and now I must think of checking the compatibility box. I certainly will forget this, and the demo program will be broken in the Fixes branch.

Not to mention all the third party programs out there which now are so nicely available by means of OPM. How will you force every developer to work in compatibility mode? And they have to change it with every demo project. It would be a bit better if there were a global option of setting the default for the compatibility box.

And I see more trouble: package lpk files still use the old format of numbered nodes. When you once decide to introduce the new format also for packages also the packages will be broken - so far it's "only" the demos.

Sorry, this is a mess.

Ok, that is a valid point. The package .lpk format should be changed the same way as the project files.
And yes, then a global option would make sense, too. I guess I must change the default value of project compatibility option to ON after all...

Juha

Juha Manninen wrote

I guess I must change the default value of project compatibility option to ON after all...

Yes that should be helpful.

BTW, there are other nodes also in the lpi files which still are counted:

* RequiredPackages
* Debugging/Exceptions
* RunParams/Modes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20190317/a2ef71e9/attachment.html>

I saw that you activated legacy compatibility mode by default, thank you. But now the checkbox in the project options is out of sync. Shouldn't it be checked now by default, too?

AM Werner Pamler wrote

I saw that you activated legacy compatibility mode by default, thank you. But now the checkbox in the project options is out of sync. Shouldn't it be checked now by default, too?

Here it is checked now by default both in existing and in new projects.

Juha

Always the same stupid error: Did not rebuild the IDE after updating from svn.

Unfortunately this does not solve the issue for me personally. I post a lot of code in the forum, and since I normally work with Laz-trunk and, of course, forget to activate the compatibility option the code will be useless for users of legacy versions. I really would appreciate to have the previous solution (a global default setting for the compatibility option) in addition to the current solution. Of course this new option should now be off by default, but after once having switched it on all my demo projects would be readable also by legacy Lazarus. I reopened bug report https://bugs.freepascal.org/view.php?id=22752 for this request.

From the perspective of a legacy Laz user a stand-alone tool to convert the new format back to legacy would be helpful, too. Currently, a user not having Laz trunk is unable to open any projects saved by Laz trunk without editing the xml files manually!

Most users still are not aware of this change - see discussion following https://forum.lazarus.freepascal.org/index.php/topic,44161.msg316081.html#msg316081. I think this is an important point to be listed
inhttp://wiki.freepascal.org/Lazarus_2.2.0_release_notes.

Werner

Feel free to extend the feature to your wishes. I don't think anybody will be against such a global option or an external stand-alone converting tool.

Ondrej