Before we have a solid automation test, how do we declare the release is
good enough to be LTS release?
As I mentioned before, it's impossible to have a stable base or LTS release
without enough automation test.

On Thu, Jan 30, 2025 at 4:05 AM Nathan Hartman <hartman.nat...@gmail.com>
wrote:

> On Wed, Jan 29, 2025 at 8:21 AM Alan C. Assis <acas...@gmail.com> wrote:
> >
> > Hi Simon,
> >
> > Yes, but it important to prove your point using a commercially available
> > development board.
> >
> > NuttX (just like Linux) is a moving target. So one out of tree board
> always
> > will break because people are constantly changing the building system and
> > moving things of place.
> >
> > There is no simple way to avoid this evolution. Unfortunately! So, those
> > companies using NuttX could stick to a fixed release or use some
> automatic
> > patching process to detect issues early and report to us.
> >
> > BR,
> >
> > Alan
>
>
> The moving target does present a difficulty when trying to develop a
> product with NuttX that needs to be maintained and updated over time.
>
> There is a way to solve the moving target problem without limiting the
> speed of NuttX development:
>
> LTS Releases.
>
> Normal development can continue at full speed and new releases can be
> made every 3 months.
>
> But once in a while, such as every 2 years, we could make a LTS
> release. For this release, we would create a branch in the NuttX repo.
> After the LTS release is published, only bug fixes and security fixes
> can be backported to the LTS branch. We would keep each LTS release
> alive for 4 years. That means that in 4 years, we will deprecate the
> oldest LTS and publish a new LTS, and we will always have 2 active LTS
> lines.
>
> People who need stability can use the LTS line. If they need to add
> custom in-tree drivers or boards, they can base their private branch
> on the LTS branch.
>
> People who need faster development can work from master and the
> regular (non-LTS) releases.
>
> The time frame of 2 years and 4 years isn't set in stone. It's just an
> initial suggestion.
>
> Cheers,
> Nathan
>

Reply via email to