Semantic Versioning

[bzgec]

I see that this repository now uses versioning/tags. I think that it would be appropriate to use Semantic Versioning.
As far as I know this is quite a standard for bigger projects (including lvgl - see lvgl tags).

To summarize Semantic Versioning:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

[stale]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tore-espressif]

Commenting to remove stale label.

[stale]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[septatrix]

Still relevant

[C47D]

@tore-espressif @kisvegabor I guess we could work on this, maybe making a new branch called v7.x, this branch will support LVGL v7.11. The master branch would keep the development for supporting LVGL v8.x, once we achieve it we could make a new branch named v8.x, leaving the master branch for development.

What do you think?

[kisvegabor]

I like this idea. It'd be in sync with the branch names of lvgl repo.

[C47D]

I already have a branch with v8 support, it might be matter of making sure we follow the same naming convention. I will wait for @tore-espressif opinion.

[tore-espressif]

I'm definitely in for making it aligned with the way LVGL does it

[C47D]

Nice, should we support the latest LVGL v7 release on the v7 branch and track the latest v8 on the v8 branch?

Should we have a branch per LVGL release or just one per major release?

[kisvegabor]

Should we have a branch per LVGL release or just one per major release?

E.g. due to a new driver related feature - let's say - in v8.4 which is used in this repo too the general release/v8 might not work for people using lvgl v.8.0. So using release/v8.x branches is more future proof IMO.

[C47D]

Can we use tags for that? On the drivers repo I mean. Or maybe start soon and figure out what to do when we face that issue.

[kisvegabor]

If we use tags and we are already on v8.4 we can't push a fix to v8.1 easily . So I think using branches is more versatile.

[C47D]

That's true, I didn't see that case. Should we create a new branch per release or just when we need a change?

[kisvegabor]

IMO we should create the branches on releases. It also allow people to simply choose a branch an occasionally pul l it to see they are any updates.

For example for cases like this I find a good approach to have driver in the lvgl repo.

[C47D]

I see, we can try that. For having the drivers in the lvgl repo i think we still need some time to mature it.

[kisvegabor]

I still believe it'd be better to these repos closer and develop drivers in a dedicated branch, but it's not critical. So I'm ok with keep it here too 🙂

I wonder it'd be easier build the architecture if we had a clean start with only one display and touch controller and add the rest later. What do you think?

[C47D]

I don't know how many people depend on this repo, I think it's better to cleanup the code base as we go.

A personal preference is move fast, maybe break a thing, and fix it quickly, there's a word for thinking too much what you want to do instead of just do it but I can't remember it right now.

[kisvegabor]

For the architecture my preference would be to see a clean and minimal picture about how things are organized.
But probably you will do more work here so let's do it as it's better for you.