doc: release_process: drop the paragraph about release freeze

[fabiobaltieri]

Drop the stable API paragraph mentioning API and feature freeze for multiple release. This hasn't been done or considered for as long as I remember and I don't think any developer really wants this.

---

...unless I'm misinterpreting the meaning of it.

[henrikbrixandersen]

Thanks. Completely forgot about needing to address this.

[cfriedt]

I was also just reading that and wondered the same thing 😅

[nashif]

not following a documented ansd agreed upon guideline calls for actions and review of why it was not followed or what the issues are, just removing that from the docs is not going to solve any problems, it is hiding them.

[fabiobaltieri]

Sounds like this should go through the Process WG right?

[nashif]

btw, this was followed for LTS2 and for LTS3 we might now have had any controversial changes coming last minute (well, aparat from hwmv2 where some kind of 'exception' was made).

Sounds like this should go through the Process WG right?

sure, but what exactly are you proposing? Removing this guideline/rule basically means anyone can rewrite the zephyr kernel and how it works 2 days before LTS feature freeze and having some of the most basic APIs/ and the core of OS ship in a completeley unstable stable state, and it should be "okay". Is this what you want?

[fabiobaltieri]

Removing this guideline/rule basically means anyone can rewrite the zephyr kernel and how it works 2 days before LTS feature freeze and having some of the most basic APIs/ and the core of OS ship in a completeley unstable stable state, and it should be "okay". Is this what you want?

The text mention freezing the API for two releases and kernel for one so the way I read it this would have prevented any stable API change from 3.5 and any kernel feature from 3.6, is that correct or am I misinterpreting it? It just does not seems like something we do.

[nashif]

The text mention freezing the API for two releases and kernel for one so the way I read it this would have prevented any stable API change from 3.5 and any kernel feature from 3.6, is that correct or am I misinterpreting it? It just does not seems like something we do.

ok, we can review the text and improve the language there, but I do not think dropping the section completely is something we want to do without any replacement/clarification...

[henrikbrixandersen]

The text mention freezing the API for two releases and kernel for one so the way I read it this would have prevented any stable API change from 3.5 and any kernel feature from 3.6, is that correct or am I misinterpreting it? It just does not seems like something we do.

I actually brought these exact paragraphs up at a release meeting at the beginning of the 3.6 development cycle.

It was my understanding, also from your comments back then @nashif, that these paragraphs were legacy and did not represent the current policy. I promised back then to bring it up to the process WG, but forgot all about it. My apologies.

It is my understanding, that if these had been followed for v3.6.0, lots of the proposed changes should have been postponed (and even HWMv2 shouldn't have gone in now).

[nashif]

It is my understanding, that if these had been followed for v3.6.0, lots of the proposed changes should have been postponed (and even HWMv2 shouldn't have gone in now).

beside hwmv2, which originally was supposed to follow this (in the original schedule from 2022) what stable kernel, base os did we break or completely overhaul?

[henrikbrixandersen]

beside hwmv2, which originally was supposed to follow this (in the original schedule from 2022) what stable kernel, base os did we break or completely overhaul?

One of the paragraphs says:

All stable APIs need to be frozen 2 releases before an LTS. APIs can be extended with additional features, but the core implementation is not modified. This is valid for the following subsystems for example:

• Device Drivers (i2c.h, spi.h)…
• Kernel (k_*):
• OS services (logging,debugging, ..)
• DTS: API and bindings stability
• Kconfig

As I read that, it basically means that our migration guides for v3.5.0 and v3.6.0 (2 releases before an LTS) should have been empty except for changes to unstable/experimental APIs? All other APIs should have been frozen except for API extensions.

[fabiobaltieri]

From the process meeting (@nashif @fabiobaltieri and @kartben) the conseus seems to be that this could use some rewording while keeping the idea of blocking core changes in the last two releases as a guideline. I'll look into reworking this PR into a rewording.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[dleach02]

can we move this out of the process working group project area or move it to done or something? Just trying to clean up the project area