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