chore: version and document fix

[kdschlosser]

I had also noticed there was some version differences in different areas of LVGL. So I write a python script that will change all of the version numbers in LVGL all at the same time.

The script gets run like this.

scripts/set_version.py 9.1.1.dev

Even if there isn't anything to set in the last space you need to still supply the dot with nothing after it.

scripts/set_version.py 9.1.1.

This will change the version located in the following files

• library.json
• library.properties
• lv_version.h
• Kconfig

Let me know if there are any that I missed and I will add them.
I have pointed everything I was able to locate to using the find_version.py script.

The CMAKE script has been updated to use this file and to do what it needs to do with the version number that has been collected.

The document build system has also been fixed, it will run and complete if there is a documentation error. A documentation error is something missing. If there is a catastrophic error in Doxygen or in Sphinx that will still cause the build to fail.

A clear and concise description of what the bug or new feature is.

[kdschlosser]

@kisvegabor

Have a look see....

[kisvegabor]

Thank you, however, we already have an open PR for update the versions: #6080

I think this PR should focus only on find_version.py.

[kdschlosser]

HA! I didn't know that PR existed. when I went looking I had noticed there were differences in the version in some of the files which is why I added the script. It can be removed easily enough... I am not fully sure as to why the other script is so complicated though. It is a pretty easy thing to update the versions and I am not sure why that other script is so complex in how it works.

However, the script I wrote doesn't update the cmake files. This PR makes a change the the cmake script to read the version using the find_version.py script. So there are some differences between the 2.

[kisvegabor]

Well, the other script is a little bit more structured, and would be shorter if it used find_version.py.

I don't think we need to set the version CMake by CMake as we will have a script to set versions anyway. Writing the version explicitly is good for readability too.

All things considered I vote for merging the find_version.py part from this PR, and use it in #6080 too.

cc @becseya

[kdschlosser]

This PR also puts find_version to use in multiple areas and it also corrects the error in the document build system. It doesn't correct it but it logs the error and allows build to continue. It has been modified so it will do this when reading the XML output from Doxygen. If there is some kind of a failure when Doxygen is running or when Sphinx is running those will cause the build to fail.

Sphinx reads the .rest files to build the HTML. The XML output from Doxygen is used to generate the .rst files that are used in the API section of the documentation. So if there is some kind of an error in the XML caused by something being missing or not correct in the docstrings located in the header files it will skip over that one piece and continue along. It will be missing from the built documentation as a result of doing that but there will be an error that is logged to let you know about the issue during the build.

[kdschlosser]

let me know what you want me to do here and I will do it. It looks like reversing the changes made for the set_version and any changes associated to that script and also reversing the changes made to the cmake file. I believe that is what needs to be done. So the new find_version script and the changes made to the documentation build system will remain.

I want to make sure that is correct before I make those changes.

[kisvegabor]

Please revert custom.cmake and remove set_version.py. After that we can merge this PR, and make #6080 use find_version.py.

[kisvegabor]

Oh, to make it even more complicated, see my comment here: #6133 (comment) 🙂

[kdschlosser]

@kisvegabor

I made the changes.

[kisvegabor]

I think we should do this:

However, with the help of this script we can hard code the version in the docs too, and update it with a script before releases.

It would keep things unified and clean. So my suggestion is:

1. remove find_version.py
2. hard code the version in docs.py and build.py
3. Update the script from feat(tools): Python script for automatically applying version (#6012) #6080 to update the version in the docs too.

What do you think?

[kdschlosser]

This is what I am thinking..

Merge the set version script into the documentation build system. This way the only way to update the version is by supplying a parameter and new version to the doc build system. The version will only keep the new version on a successful build of the documentation. If a failure occurs the version would revert back to what it was.

I like this idea because the documentation gets published when? When a new release is made. New versions only get made when new releases get made and that forces the documentation to be published.

So the requirements for making a new release is going to be the documentation building and the version number getting changed.

[kisvegabor]

The docs is rebuilt and published on every commit.

I like being explicit. If we run the version updater script manually we can check if everything were updated correctly, and commit+push the changes.

[lvgl-bot]

We need some feedback on this pull request.

Now we mark this as "stale" because there was no activity here for 14 days.

Remove the "stale" label or comment else this will be closed in 7 days.

[kdschlosser]

not stale