-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft: Release process for noglib BSPs #384
Conversation
8c92b87
to
1a4ca36
Compare
0d95729
to
cf25001
Compare
edc1549
to
fac96b3
Compare
cf25001
to
3fa0354
Compare
3fa0354
to
3dd420c
Compare
40d211d
to
514c4f4
Compare
3dd420c
to
ffa2a5f
Compare
Current solution looks okeyish. If I understand the process. Default BSP is with LVGL and then NOGLIB is reduction of existing BSP. Wouldn't it be possible to reverse the architecture, that NOGLIB is base dependency for BSP with LVGL? That would make more sense from software point of view. Instead of reduction, it will be natural extension and also scripts could be reduced. Please, note that names of BSP's are hardcoded several times in the scripts. This will lead to errors, when someone will add BSP in one place and forget to add it to another. |
I agree that this way it would be cleaner solution. The only reason why we create NOGLIB from LVGL version is historical (the original BSP contains LVGL) and so we don't create breaking change for existing BSP users
thanks, I'll have a look |
Release process for noglib BSPs
1.1. Create noglib BSPs
1.2. Build noglib example from feat(test_apps): Add noglib test_app #372
1.3. Check correctness of idf_component.yml files
2.1. Create noglib BSPs
2.2. Push changes to release/noglib
2.3. Push noglib BSPs to ESP-Registry
Related
TODO