On Fri, Jan 31, 2025 at 3:35 PM <michal.lyszc...@bofc.pl> wrote: > On 2025-01-31 13:48:32, Tomek CEDRO wrote: > > On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet <sebast...@lorquet.fr> > > wrote: > > > Of course I also tried with the commit before that one, and it didnt > > > work either. > > > > Sebastien, did you try the release packages? Does the problem occur in > > the release packages? > > > > Upstream master is for development purposes, things may get broken for > > a while, I would never put my product on a master branch. > This is offloading responsibility to end user. Sebastian is right here. > Either apps are separated properly so that even 1 year old apps repo will work > with current HEAD of rtos, or nuttx should have sync mechanism like submodules > (don't go there) or tool like Zephyr's west to sync it (or it can also be > done with make/cmake). > > Did you ever try to bisect problem in nuttx? Constant failures in apps and you > have to manually guess which commit is going to at least compile - and then > you > still cannot be 100% sure soft does/doesn't work as indended.
Hmm, I get it. I saw that too. I thought it should be always in sync. I saw changes in either nuttx or nuttx-apps that depends on each other. Not sure if that would allow apps to build / work on one year old rtos code. So what are your solution propositions? 1. Prevent nuttx-apps modification when something changes on nuttx side that would break backward rtos compatibility? How to make updates then? 2. Add CI action that would build nuttx-apps on older nuttx to make sure compatibility is maintained? What if build fails and update is necessary? 3. Extend CI build of all possible apps and see how nuttx change impacts nuttx-apps side in depth and what needs an update too? But then still we have no compatibility as apps will be updated too. Usually OS has something called API and apps must adhere to that API. If breaking change is introduced API number is bumped and so apps needs an update. We should discuss and vote this kind of design decision and put inside CONTRIBUTING and documentation f anything changes. Also I welcome everyone to help in PR review if changes are impacting you, catch them first before merge :-) Looking at documentation: https://nuttx.apache.org/docs/latest/quickstart/install.html Apache NuttX is actively developed on GitHub. There are two main repositories, nuttx and apps, where the latter is technically optional (but recommended for complete set of features). If you intend to contribute changes, you need the absolute latest version or you simply prefer to work using git, you should clone these repositories (recommended). Otherwise you can choose to download any stable release archive. There is no mention that current apps code guarantee compatibility with older rtos versions code. Instruction says either use "absolute latest version", "clone repositories", "otherwise you can choose to download any stable release archive". For me it means I need to have both nuttx and nuttx-apps in sync or use release packages. Greg what you think? :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
