chore: version and document fix #6143
Conversation
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. ```shell 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. ```shell 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.
The original find_version.sh script only returned major.minor and this needed to be able to be duplicated.
|
Have a look see.... |
|
Thank you, however, we already have an open PR for update the versions: #6080 I think this PR should focus only on |
|
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. |
|
Well, the other script is a little bit more structured, and would be shorter if it used 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 cc @becseya |
|
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 |
|
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. |
|
Please revert |
|
Oh, to make it even more complicated, see my comment here: #6133 (comment) 🙂 |
� Conflicts: � scripts/find_version.sh
|
I made the changes. |
|
I think we should do this:
It would keep things unified and clean. So my suggestion is:
What do you think? |
|
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. |
|
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. |
|
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. |
|
not stale |
|
I still believe it would be simplest and cleanest way:
|
|
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. |
|
It should be fixed before releasing v9.2 (targeting August 26) |
|
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. |
|
I wouldn't dare to touch it before the release. It seems to be working, so let's leave it as it is for now. |
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.
Even if there isn't anything to set in the last space you need to still supply the dot with nothing after it.
This will change the version located in the following files
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.