Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

tore-espressif
Copy link
Collaborator

@tore-espressif tore-espressif commented Aug 28, 2024

Release process for noglib BSPs

  • noglib BSPs will be released from release/noglib branch
  • release/noglib branch is updated with 'merge' strategy (not rebasing) to preserve git history
  • There are 2 stages in the process
  1. Check
    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. Release (only on master branch)
    2.1. Create noglib BSPs
    2.2. Push changes to release/noglib
    2.3. Push noglib BSPs to ESP-Registry

Related

TODO

  • Update documentation!
  • Write PR description

@tore-espressif tore-espressif changed the base branch from master to feat/noglib_example August 28, 2024 11:40
@tore-espressif tore-espressif self-assigned this Aug 28, 2024
@tore-espressif tore-espressif marked this pull request as ready for review August 28, 2024 12:46
@tore-espressif tore-espressif force-pushed the feat/noglib_process branch 10 times, most recently from 0d95729 to cf25001 Compare August 29, 2024 07:53
@tore-espressif tore-espressif changed the title Feat/noglib process Release process for noglib BSPs Aug 29, 2024
@tore-espressif tore-espressif force-pushed the feat/noglib_example branch 2 times, most recently from 40d211d to 514c4f4 Compare September 4, 2024 08:49
Base automatically changed from feat/noglib_example to master September 9, 2024 06:55
@tore-espressif
Copy link
Collaborator Author

@georgik @igrr This is a proposal how to relase noglib BSP versions. PTAL at the PR description and READMEs to find out more!

@georgik
Copy link
Contributor

georgik commented Sep 9, 2024

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.

@tore-espressif
Copy link
Collaborator Author

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.

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

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.

thanks, I'll have a look

@tore-espressif tore-espressif changed the title Release process for noglib BSPs Draft: Release process for noglib BSPs Sep 20, 2024
@tore-espressif tore-espressif marked this pull request as draft September 20, 2024 09:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants