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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
