Roger that Alin! So the next release is major bump (13) to mark introduction of bigger changes and when these are ready we bump again (14)? Occam's razor? :-)
-- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Thu, Feb 19, 2026 at 2:28 PM 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 > > > > > > > > > > > > > > > > > > > > > > > > > >
