Hi Alin, That makes sense! Maybe we could consider doing another 12.x release this quarter then and saving 13.0.0 for the next quarter? What do you think?
Matteo On Thu, Feb 19, 2026, 10:28 AM Alan C. Assis <[email protected]> wrote: > Yes, I was not aware of 14 too, but when I was in Shenzhen some years ago, > I noticed some elevators skip the number 4. > > It could become a xkcd comedy: we end-up not using a number because any > number is bad luck in some countries. :-) > > > > On Thu, Feb 19, 2026 at 12:17 PM Matteo Golin <[email protected]> > wrote: > > > That is actually interesting. Anecdotally, here in Waterloo there is a > > significant Chinese community and so there are actually many apartment > > buildings which do not have a 13th floor due to the superstition. Of > > course, the 13th floor exists, but it is given a different number. > > > > I would say I'm not strictly against using 14.0.0 or even 15.0.0 (I see > 14 > > is also unlucky in the Suse link) instead for the release. I don't think > > any NuttX users have mentioned this issue on the 13.0.0 discussions > before > > though. > > > > Matteo > > > > On Thu, Feb 19, 2026 at 10:09 AM Alan C. Assis <[email protected]> > wrote: > > > > > Yes, I think we can postpone branching the release 13.0.0 to include > the > > > most important breaking changes on it (otherwise there is no need to > > > increase the release digit if there are not significant changes). > > > > > > > > > > > > On Thu, Feb 19, 2026 at 12:02 PM Matteo Golin <[email protected]> > > > wrote: > > > > > > > Hi all, > > > > > > > > May I provide an alternative view: 13 is a lucky number for Italians > :) > > > > > > > > In all seriousness, I do agree that March 1 might be a bit early for > > the > > > > 13.0.0 release. I know there are several other tasks on the issue > > tracker > > > > for it, so I don't want to push it along with my changes here > > > prematurely. > > > > I'm not sure if the time representation getting pushed from 32b to > 64b > > > has > > > > been merged, but I also wanted to tackle the empty apps docs and the > > > > README.txt files for the big release. If we can bundle more breaking > > > > changes in time for 13.0.0 that is better, I think. I don't mind > > > > "maintaining" the init patch (since it's a moving target) as the > other > > > > changes are getting ready; I don't think it would be too involved. > > > > > > > > I think releasing a 13.0.0 is fine anyways. I honestly don't think > very > > > > many upstream patches from 12.x users are going to be affected. There > > > > really aren't many crazy breaking changes to be in 13.0.0 yet, most > > APIs > > > > are the same. I also agree that there is too much involved in having > an > > > LTS > > > > or a separately maintained internal version. I would be in support of > > > > delaying the release for a longer testing period given the major > > version > > > > bump, but I don't think we should treat 13.0.0 too much differently > > from > > > a > > > > regular release. > > > > > > > > In terms of the actual change I'm making to the init, I think it is > > > quite a > > > > large benefit because it finally prevents all the NuttX boards from > > > relying > > > > on user space code (NSH/boardctl) to bring up the board. I > encountered > > > this > > > > issue a few times myself when trying to make my own apps an entry > point > > > for > > > > NuttX. It is definitely not the only thing that could be done for the > > > boot > > > > process, and I agree that we can also focus on documenting it better. > > > But, > > > > I don't think there is a reason to object to this change and it has > > been > > > > discussed/desired by the community for a long time. I'm happy to > > explain > > > > the change in more detail if my PR descriptions/the issue discussion > > > aren't > > > > clear enough! > > > > > > > > Question for Alin: what is the normal process for breaking changes in > > > > releases? I'm wondering if its possible to merge into mainline and > just > > > > wait longer between the current version and 13.0.0 as other breaking > > > > changes catch up in development. That way mainline is the "draft > > 13.0.0" > > > > and doesn't need special maintenance. Of course, if this doesn't fit > in > > > the > > > > usual release process, I am happy to maintain the patch branch until > > > things > > > > are ready! > > > > > > > > Best, > > > > Matteo > > > > > > > > On Thu, Feb 19, 2026, 9:22 AM raiden00pl <[email protected]> > wrote: > > > > > > > > > No one serious will avoid NuttX because it's version 13. Let's be > > > > > serious, this > > > > > is a community of engineers, not stock market traders. Don't waste > > time > > > > > discussing superstitions, because it's starting to look like AI > bots > > > > > discussion ;) > > > > > > > > > > czw., 19 lut 2026 o 15:12 Alan C. Assis <[email protected]> > > > napisał(a): > > > > > > > > > > > But it will make it difficult to get their patches integrated > into > > > the > > > > > > mainline, since 12.x to 13.x will have a big difference. > > > > > > > > > > > > NuttX 12.0.0 was released on 2023-01-16, more than 3 years ago, > so > > I > > > > > > suppose if we follow the same logic, users that decided to use an > > old > > > > > > version could be using a version from more than 3 years ago. > > > > > > > > > > > > We already have many issues in the project to worry about, having > > > users > > > > > > avoiding using NuttX just because it has a 13.x release is > > something > > > I > > > > > > think we can skip, we can avoid! :-) > > > > > > > > > > > > BR, > > > > > > > > > > > > Alan > > > > > > > > > > > > On Thu, Feb 19, 2026 at 11:00 AM Alin Jerpelea < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > such separation will be hard to maintain and will produce > > confusion > > > > > > > > > > > > > > I think that it is better to have 13.xx.xx released on the > normal > > > > cycle > > > > > > and > > > > > > > let users decide if they use the "stable 12.xx.xx releases" or > > the > > > > "new > > > > > > > 13.xx.xx" > > > > > > > I can add a Note to the release notes to clarify that 13.0.0 > may > > > need > > > > > > some > > > > > > > releases to shine > > > > > > > > > > > > > > Best regards > > > > > > > Alin > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 19, 2026 at 2:45 PM Alan C. Assis < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > > > Yes, I think LTS is not the way to go. > > > > > > > > > > > > > > > > But I agree with Tomek to keep version 13 as internal usage > > only, > > > > not > > > > > > for > > > > > > > > final users and companies. > > > > > > > > > > > > > > > > BR, > > > > > > > > > > > > > > > > Alan > > > > > > > > > > > > > > > > On Thu, Feb 19, 2026 at 10:28 AM Alin Jerpelea < > > > [email protected] > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > With the resources available we can not start a LTS track > > > > > > > > > I propose that we continue using, for now, the same release > > > > > procedure > > > > > > > > > > > > > > > > > > Best regards > > > > > > > > > Alin > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 19, 2026 at 1:57 PM raiden00pl < > > > [email protected] > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > LTS was discussed on this list earlier, and the > conclusion > > > was > > > > > that > > > > > > > the > > > > > > > > > > project > > > > > > > > > > didn't have the resources to maintain LTS release. I > don't > > > > think > > > > > > > > anything > > > > > > > > > > has > > > > > > > > > > changed since then in terms of resources available (or > > > should I > > > > > say > > > > > > > > it's > > > > > > > > > > worse now?), > > > > > > > > > > so bringing LTS release idea into this discussion doesn't > > > make > > > > > much > > > > > > > > > sense. > > > > > > > > > > > > > > > > > > > > czw., 19 lut 2026 o 13:44 Tomek CEDRO <[email protected]> > > > > > > napisał(a): > > > > > > > > > > > > > > > > > > > > > Or we could resemble FreeBSD organization to match > > > > progressive > > > > > > and > > > > > > > > > > > conservative crowd: > > > > > > > > > > > 1. CURRENT is the master experimental branch (i.e. > > > > 13-CURRENT). > > > > > > > > > > > 2. STABLE is well tested and not breaking branch (i.e. > > > > > > 12-STABLE). > > > > > > > > > > > 3. RELEASE is snapshot of STABLE in time marked with > > number > > > > > > branch > > > > > > > > > > > (i.e. 12.12-RELEASE). > > > > > > > > > > > > > > > > > > > > > > When CURRENT gets mature it goes STABLE (branch), bumps > > > > number > > > > > > and > > > > > > > > > > > starts experimenting (branch) again. STABLE gets > updates > > > and > > > > > > fixes > > > > > > > > > > > from CURRENT, but it also serves as source for RELEASE > > > > (branch) > > > > > > > from > > > > > > > > > > > time to time. If you need some fix from STABLE but you > > use > > > > > > RELEASE > > > > > > > > you > > > > > > > > > > > can build it safely.. except release is also tied to > some > > > > tools > > > > > > > > > > > packages etc. Stability here in terms of API. Plus > > "compat" > > > > > layer > > > > > > > > that > > > > > > > > > > > provides cross-version ABI compatibility (i.e. 10.0 > > binary > > > > > works > > > > > > > fine > > > > > > > > > > > on 14.3). > > > > > > > > > > > > > > > > > > > > > > https://www.freebsd.org/releng/ > > > > > > > > > > > https://docs.freebsd.org/en/articles/freebsd-releng/ > > > > > > > > > > > > > > > > > > > > > > It may sound fun but still a lot of maintenance work > for > > a > > > > > small > > > > > > > > > > > team.. maybe too much.. or just some inspiration :-) > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 19, 2026 at 1:17 PM Alan C. Assis < > > > > > [email protected] > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > That is a good idea! > > > > > > > > > > > > > > > > > > > > > > > > The number 13 could be like a transition (passage) > > > version, > > > > > it > > > > > > > > could > > > > > > > > > be > > > > > > > > > > > > considered a breaking version, before the final > version > > > > > > release. > > > > > > > > > > > > > > > > > > > > > > > > In this version we will have the chance to improve > the > > > boot > > > > > > > > > > > initialization > > > > > > > > > > > > and other things, i.e.: currently we have the common > > > boards > > > > > > that > > > > > > > > have > > > > > > > > > > > > drivers shared in the same chip family, but it is > > > possible > > > > to > > > > > > > > extend > > > > > > > > > > this > > > > > > > > > > > > idea to have these drivers working for all chips. > > > > > > > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > > > > > > > > > BR, > > > > > > > > > > > > > > > > > > > > > > > > Alan > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 19, 2026 at 9:07 AM Tomek CEDRO < > > > > > [email protected]> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
