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