How do you want to maintain compatibility between nuttx-apps and nuttx while both are active development projects, and what's more one of them is optional? It's not possible.
It would be possible if we assumed that the API in NuttX is perfect and will not require changes, which is not true. There are many custom solutions in NuttX that require improvements and these improvements will break compatibility. There are many custom interfaces that need improvement, such as PWM or sensors, and these changes will definitely break apps. On the other hand, any standardized interface like POSIX must be stable, which is obvious. But POSIX doesn't define everything, especially when it comes to embedded systems. pt., 31 sty 2025 o 17:30 Sebastien Lorquet <sebast...@lorquet.fr> napisał(a): > hello > > My proposal is: > > 1) define how the app build system is invoked and never move that > > 2) define that nuttx expects apps in a particular file at a particular > place and never move that. > > Also, enfore the use of the posix api everywhere. that should be enough... > > the app/os limit is probably in the inviolables... (I did not check) > > Sebastien > > > On 31/01/2025 16:20, Tomek CEDRO wrote: > > 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 >
