I was only skim reading the discussions on LTS, so probably missed
detailed descriptions/conclusion of the LTS proposal. It seems a great
idea but @raiden00pl makes a valid point I think?
This is a vote for 13.0.0 which is an LTS candidate I would imagine.
Once out in the wild, any fixes (not enhancements, additions etc) would
be applied until it is deemed stable, then a vote on 13.0.1LTS would be
made.
So any PRs that relate to 13.0.1LTS need a procedure to mark them as
such, or a 13.0.1LTS branch created at the same time as 13.0.0 is
released perhaps and "fix" PRs based on that baseline? Or a suitable tag
to the PR allows a backport to 13.0.0 for the 13.0.1LTS release?
Other PRs that are not fixes but enhancements would become 13.0.2 perhaps?
Is that right? Does it make sense?
On 26/02/2025 09:59, raiden00pl wrote:
we only need separate commits not PR which is a best practice and improves
readability
Lately I've been seeing something completely different on Github...
Separate commits are OK, separate PRs are not.
We can provide fixes and improve the LTS releases compardd with the
regular
releases which brings a stability benefit for users that maintain oftree
boards
I understand that, but shouldn't the first LTS release be tested and
stable?
Something that is marked LTS and is not tested from the very beginning
makes
a bad impression about the project. Quality assurance first - then we can
think about LTS.
śr., 26 lut 2025 o 10:50 Alin Jerpelea <jerpe...@gmail.com> napisał(a):
On Wed, 26 Feb 2025, 10:32 raiden00pl, <raiden0...@gmail.com> wrote:
-1 from me.
1. It's a waste of already limited resources in this project.
2. It makes life harder for contributors, by for example requiring
separation of PRs on arch/boards/doc. Extra work for contributors to
compensate for the project's limited resources is not okay.
we only need separate commits not PR which is a best practice and improves
readability
3. Regarding the above point: I don't see the point in separating changes
that MUST BE implemented together. In this way, error detection by
CI won't be impossible in some cases.
4. LTS should have some quality assurance, which involves testing as many
features as possible in the current NuttX. Otherwise it makes no sense.
At this time, NuttX doesn't have the resources for this.
We can provide fixes and improve the LTS releases compardd with the regular
releases which brings a stability benefit for users that maintain oftree
boards
śr., 26 lut 2025 o 10:08 Alin Jerpelea <jerpe...@gmail.com> napisał(a):
This vote proposes to start the LTS releases for NuttX RTOS
The proposed LTS release plan is
- 1st release each year is a LTS release (maintained for 1.5 years)
- 6 minor releases for each release
ex: 13.0.0-13.0.6 for our first LTS release
Voting will be open for 72hr.
A minimum of 3 binding +1 votes and more +1 binding than -1 are
required
to
pass.
Best regards
Alin
