Must have stability patches for v7.1.0

Applications
#1

Hello,

we are using lvgl in a industrial control application. Currently we use the release version v7.1.0. Now we hit a bug that has been fixed by a later commit (1). The newer versions (like v7.10.1) are introducing a lot of new stuff beneath bugfixes. That makes it a bit of a risk to just upgrade to this version because it would void all prior test results. Is there a list of must have stability fixes for older versions?

Best regards

Christian Mauderer

(1) this one https://github.com/lvgl/lvgl/commit/28213adfa62f70fa3a25b10baf305b99bbc14436

#2

We don’t really support older minor versions because nothing should break when upgrading. An application written for 7.1.0 should still work on 7.10.1 unless it relies on buggy behavior.

If something does break, it’s a bug, and should be reported on GitHub.

For the newer releases, we have started keeping a changelog, so that might be helpful.

In this case, I would suggest cherry-picking the relevant commit and applying it to 7.1.0.

#3

(cc @kisvegabor)

#4

I can also suggest the same if you find it risky to update to the latest minor release.

@embeddedt The concern of @c-mauderer is quite reasonable. Having less, but more mature minor releases sounds good. For v8 we have decided to have 1 minor release per month, but 1 minor release per 2 months seems also reasonable. What do you think?

#5

Hmm… the problem with this is that bugfixes get delayed for 1.5-2 months. Other projects work around this by having more people on their core team, so they have extra man-hours to spare keeping track of fixes to cherry-pick to old point releases.

The issue is that LVGL doesn’t have that kind of bandwidth at the moment.

#6

We can have bug fix releases on-demand, even every week if required.

1 Like
#7

@embeddedt and @kisvegabor: Thanks for the responses. I’ll make sure to take a look at the Changelog.

I can understand the problem with the extra overhead. It’s a problem that a lot of projects have (including the one where I’m a bit more active: RTEMS). For open source projects time without funding always has to be interesting so that someone want’s to do it.

Please also note that I don’t have a problem with bugfixes in the releases between 7.1.0 and 7.10.1. What I’m worried about are new features like the “Style caching” in https://github.com/lvgl/lvgl/commit/41fd83e1d326da37210fc8bdbdc851e79c1683eb. These are bigger changes that might introduce new bugs and therefore would need extensive new testing of the application.

From a user perspective it would be ideal if such changes would be on another branch. Meaning: One branch with “stable but old” 7 version where bug fixes are cherry picked but no new features or big structural improvements are added. And one with lots of improvements that would sometimes in the future will result in a version 8.0.

Again: I understand why it doesn’t exist. Reason is that there is not enough unfunded time. And at the moment I’m not sure how it could be made funded time. But I think especially for industrial projects it would be a great feature.

BTW: I think the question about a LTS version in Version lifecycle and LTS versions had a similar background.

1 Like
#8

@c-mauderer
We will discuss it in detail for v8 and figure out something.