Add a release script

[kisvegabor]

Problem to solve

We need a reliable was to update all the version numbers in

• lv_conf_template.h
• lvgl.h
• library.json
• library.properties
• lvgl.pc.in

Success criteria

There is script which updates all these

Solution outline

Having a Python script with some sed calls seems simple. It could work like:

python3 update_version.py 9.1.2
python3 update_version.py 9.1.2-dev

Rabbit holes

Can't think of anything.

Testing

Hard to test...

Teaching

Internal tool, having comments at beginning of the file and a --help should be enough.

Considerations

No response

[becseya]

This seems pretty straightforward, I'd be happy to take this issue.

One thing that comes to my mind is "live" versioning, where the current version (git describe) is reflected in the compiled artifact. It's quite useful during development in my experience. Would it be considered for addig now or in the future?

[XuNeo]

Currently the version is hard coded in header file. It does not take git commit hash into consideration.

[becseya]

I've concluded the same. I was just wondering if it would be desirable to use the git commit hash as a new feature. (in this ticket or adding to backlog)

[kisvegabor]

If we would add the git hash we needed to update all files containing the version in each PR which has multiple issues:

• to commit hash is known only after merging
• makes contribution more complicated (we need to enforce this rule)
• it adds "noise" to the PRs

Now we append the -dev suffix for under development versions. We can find out a better word or strategy for that, but I think from the script's point of view it's enough if it can overwrite the major, minor, and patch version numbers, and the info string. Later we can figure out how to use it the most efficient way.

What do you think?

[becseya]

What I have imagined does not affect files in each commit/merge:

• make and cmake build system is extended with a mechanism that detects the presence of git versioning system
• when it's present, it adds -DLVGL_VERSION_INFO=<git_hash[-dirty]> as compiler option
• LVGL_VERSION_INFO gets an #ifndef guard in lvgl.h

Package files are left out, as I'd not expect users grabbing non-release versions from package managers. (This makes me realize, why lv_conf_template.h needs to be updated?)

[kisvegabor]

What I have imagined does not affect files in each commit/merge: [...]

We can do that, and the fallback for LVGL_VERSION_INFO in lv_conf.h could be "dev".

However I wonder where can we use and see -DLVGL_VERSION_INFO=<git_hash[-dirty]>. We will print it as a start up log?

Package files are left out, as I'd not expect users grabbing non-release versions from package managers.

Makes sense. The users still need to be able to check the used LVGL version manually by looking into the files, however your proposed approach doesn't prevent that.

This makes me realize, why lv_conf_template.h needs to be updated?

Good question. lv_conf.h (which was copied from lv_conf_template.h) might not be updated when lvgl is updated. So it might be useful for the user to see which lvgl version his/her lv_conf.h belongs to.

[becseya]

These are all good points, I don't see clear benefit of -DLVGL_VERSION_INFO.

Let's drop it and I'll go ahead with the original issue.

[becseya]

As of latest master branch, lvgl.h has the -dev part, but package files does not. Is this intentional and package files are updated only on release?

[becseya]

I've found 4 other occurences:

• Kconfig I think it should be added to the list
• .devcontainer/__lv_conf.h__ This one is outdated. Is that intentional?
• env_support/cmsis-pack/lv_conf_cmsis.h I see there is some manual generation involved, so I'd leave it out.
• env_support/cmsis-pack/LVGL.pidx This one is also one version behind, but different form the conf. Also using -dev1, is that expected?

[becseya]

I was thinking about adding a check in CI/CD. It's a bit awkward, since if the new version files are pushed with a branch rather than a tag, the check will fail. One solution could be to define a keyword which can be detected in the commit message, and that overrides the version to expect. How well would it fit to the current release procedure?

Also I've found def update_version(ver) in scripts/release/com.py. Should that be replaced with the new mechanism?

[kisvegabor]

env_support/cmsis-pack/lv_conf_cmsis.h I see there is some manual generation involved, so I'd leave it out.

env_support/cmsis-pack/LVGL.pidx This one is also one version behind, but different form the conf. Also using -dev1, is that expected?

@GorgonMeducer could you take look at this?

I was thinking about adding a check in CI/CD. [...]

There are multiple things to do before a release

1. Generate changelog an manually improve it a little.
2. Update the version defines/strings
3. Add and push the tag
4. Merge the new version to a release/v* branch
5. Update the LVGL submodule in the lv_port_* repos (also update their release/v branches)

Probably we can automate some steps. I think for 2 and 3 an offline script (sh or py) would be enough to have better control. However for 4 and 5 a CI/CD would be really nice!

Let's focus on the version update now, and figure out the rest step by step.

Also I've found def update_version(ver) in scripts/release/com.py. Should that be replaced with the new mechanism?

The release folder is outdated and shall be removed. Of course if you find some useful code in it, feel free to reuse some parts.

[GorgonMeducer]

env_support/cmsis-pack/lv_conf_cmsis.h I see there is some manual generation involved, so I'd leave it out. env_support/cmsis-pack/LVGL.pidx This one is also one version behind, but different form the conf. Also using -dev1, is that expected?

Yes, this is all right. Please leave them there.

[lvgl-bot]

We need some feedback on this issue.

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.

[kisvegabor]

Not stale