Well I also know some people in person that avoid 13 at all cost it is quite funny.. but for me 13 is kinda lucky even if in a different way.. we may consider 13 internal testing and then just go 14.. whatever :D :D :D
-- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Thu, Feb 19, 2026 at 12:44 PM Alan C. Assis <[email protected]> wrote: > > I agree! Also we need to decide whether to use the number 13 or will skip > it! :-) > > Historically it is proved that this number is not good luck, even NASA when > tried to insist on it (what could go wrong, NASA has the smartest people on > the planet), that resulted in a catastrophic event that almost ended up > with the life of 3 persons. > > Ok, maybe I'll writing it as a joke, but imagine someone considering to use > NuttX, if they have any doubt they will not use NuttX 13 for sure! :-D > > So, I vote for NuttX 14 :-D > > BR, > > Alan > > On Thu, Feb 19, 2026 at 8:22 AM Tomek CEDRO <[email protected]> wrote: > > > I would not rush with the 13 and keep it for time when most breaking > > things are settled and we could call it first LTS release, until then > > stick to 12 and small improvements in minor releases, but I will > > follow the community voice :-) > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > On Thu, Feb 19, 2026 at 7:23 AM Alin Jerpelea <[email protected]> wrote: > > > > > > Hi Matteo, > > > > > > I will fork the next release branch on 1st of March so that we have 1 > > month > > > to test the release. > > > > > > I propose that we name this release 13.0.0 and we put all planned > > breacking > > > changes in the new release > > > > > > Best regards > > > Alin > > > > > > On Thu, 19 Feb 2026, 06:47 Matteo Golin, <[email protected]> wrote: > > > > > > > Hello everyone, > > > > > > > > I have decided to work on tackling this issue: > > > > https://github.com/apache/nuttx/issues/11321 > > > > > > > > The crux of it is: many boards rely on NSH to initialize > > > > peripherals/board-level systems. This is done through the user-space > > call > > > > to boardctl(BOARDIOC_INIT). However, BOARD_LATE_INITIALIZE also does > > the > > > > same thing. This is confusing for many users and also results in boards > > > > having out-of-sync init methods (i.e. late_init does something > > different > > > > than app_init, but they shouldn't). To simplify the initialization and > > > > reduce user confusion, the suggestion was to completely remove > > > > BOARDIOC_INIT/board_app_initialize and NSH_ARCHINIT in favour of > > > > BOARD_LATE_INITIALIZE. This is a massive breaking change and was put > > on the > > > > to-do list for 13.0.0 but it hadn't been picked up yet and we're still > > in > > > > time for 13.0.0. > > > > > > > > I have a draft PR open here to the kernel with most of the boards > > adhering > > > > to the new changes: https://github.com/apache/nuttx/pull/18408 > > > > > > > > And here to the apps repo removing references to BOARDIOC_INIT and > > > > NSH_ARCHINIT: https://github.com/apache/nuttx-apps/pull/3405 > > > > > > > > These PRs are large, introduce breaking changes, and touch many > > different > > > > boards (not all of which I am able to test on my limited hardware > > set). I > > > > would appreciate eyes on these PRs to see if there are any flaws in my > > > > initial approach and also in case anyone would like to volunteer to > > test > > > > the changes on some hardware (I don't own anything with an STM32 for > > > > instance). > > > > > > > > The CI is also going to report a lot of errors due to the changes being > > > > across both repositories (and they will be out of sync with each other > > in > > > > the CI runs), hence the importance of testing :) > > > > > > > > Thanks for your feedback in advance (and maybe your time testing if you > > > > can!) > > > > Matteo > > > > > >
