I propose that for our first LTS we start with a small scope and we backport only fixes, new hw and drivers
For the future releases we may consider expanding the scope if the workload permits What do you think ? On Tue, Feb 11, 2025 at 10:55 AM Laczen JMS <laczen...@gmail.com> wrote: > Hi Alin, > > I also encourage this. I would start by defining what is expected from a > LTS: > > A LTS release of NuttX is a release that will be maintained and > supported over a longer period of time (1 year). > LTS updates are mainly focused on bugfixes that where discovered and > corrected during the support period. > These bugfixes will be backported to the LTS release. > > Should new features and hardware be allowed in a LTS? If so, how many > releases should they have been in? > Many users will keep there own defconfig for a certain product, should > they remain valid? If so are Kconfig changes allowed? > > Anyhow thanks for the proposal, > > Jehudi > > Op di 11 feb 2025 om 10:02 schreef Michael Jung <michael.j...@secore.ly>: > > > > Hello Alin, > > > > I would love to see this, as it would make maintaining our product much > > easier. > > > > Thanks for the proposal. > > > > Michael > > > > On Tue, Feb 11, 2025 at 9:55 AM Alin Jerpelea <jerpe...@gmail.com> > wrote: > > > > > Hi all, > > > > > > there have been suggestions that we should create LTS releases > > > > > > I propose that we mark every Q1 (match) release as a LTS release and > > > maintain it for 2 years. this would always ensure a fresh LTS > overlapping > > > the old one and allowing the users to migrate the code to the new > release. > > > > > > What do you think? > > > > > > Best regards > > > Alin > > > >
