Hello,
I agree. Only bugfixes, criticity threshold to be determined, but new
features seem unnecessary to me.
Sebastien
On 11/02/2025 12:43, Tiago Medicci Serrano wrote:
Hi,
I would make the scope even more restricted. Considering an LTS should be
100% compatible with an existing defconfig, it should not add new drivers
and new HW. I propose it to contain only bugfixes and security patches.
Best regards,
Em ter., 11 de fev. de 2025 às 08:27, Alin Jerpelea <jerpe...@gmail.com>
escreveu:
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
