Out of curiosity OpenBSD (flavors) and NetBSD (pullups) seems to have similar approach :-)
https://www.openbsd.org/faq/faq5.html#Flavors https://www.netbsd.org/developers/releng/pullups.html -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Thu, Feb 19, 2026 at 1:43 PM Tomek CEDRO <[email protected]> wrote: > > 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 > > > > > > > > > > > > > > >
