RFC: Torizon OS 7 release will require a new branch

[leonheldattoradex]

With Torizon OS 7 we'll need to bump the base containers to the major 4 and thus a new branch, because we also need to maintain the containers based off of Torizon OS 6.

Please drop below some ideas for this.

[leograba]

What is the strategy adopted on https://github.com/torizon/torizon-containers? Could we use the same?

[andreriesco]

Also, we need to define the samples on which branches do we plan to bump? Both bookworm and bookworm-new? Or should we maintain just one branch in the future for Torizon OS 7?

[leograba]

bookworm is dead, it can be renamed to whatever so we keep it for history, because we don't have a 1:1 port to bookworm-new.

bookworm-new would become bookworm someday when all samples were migrated, but it seems that will never happen.

In summary, for the sake of this discussion, I'd assume there is a single bookworm branch. And then, if we want to discuss the bookworm-new vs bookworm, to do it in another issue.

[leonheldattoradex]

@leograba well I didn't want to propose that here because I kinda already did on torizon-containers so I wanted to let people think a little :) But yes, it's a very plausible strategy.

Just for everyone to know, we adopted stable, oldstable and next there instead of the codenames. Stable is always based off of the latest major release, oldstable from the previous one.

[escherstair]

Based on what I understood, we should always consider 3 items in the picture:

• Torizon OS
• Yocto
• Debian

Every major release of Torizon OS is based on a LTS of Yocto and so:

• Torizon OS 6 - kirkstone
• Torizon OS 7 - scarthgap

The release of Debian is much more involved when we talk about which is the base image for the containers.
I'm not sure if this is the same base used in the Torizon OS recipe.
If this is the case, I would say that both Torizon OS 6 and 7 are based on Debian bookworm.
But in this way, why the need for a new branch for Torizon OS 7?
I think that something more than Debian release is involved in the branches.

In this moment, stable is bookworm and oldstable is bullseye (Debian terminology), but soon or later in the future, stable would be trixie, and oldstable would be bookworm.

The naming convention of stable and oldstable comes from Debian, and so for me it's ok if the only difference between the branches (and their usage) is the Debian release.
If we want to differentiate the branche on Torizon OS release, I would prefer names referring to Yocto names (kirkstone, scarthgap) and/or Torizon OS release numbers.

If I misunderstood the situation, feel free to correct me.

[leograba]

@escherstair the devil is in the downstream BSPs.

• Torizon OS 6 is based on Toradex BSP 6, which is based on the community BSP built on top of NXP BSP 5.15.y
• Torizon OS 7 is will be based on Toradex BSP 7, which is based on the community BSP built on top of NXP BSP 6.6.y

Due to this, even if the Debian release used as the base of Debian Containers for Torizon is Bookworm for both, we`d still need two flavors of Bookworm:

• Bookworm + NXP user space packages that match NXP 5.15.y
• Bookworm + NXP user space packages that match NXP 6.6.y

I suggested adopting the same as in torizon-containers because I'd assume they already had to go through the same thought process and deal with the same issue.

A question remains: if two different base containers must be built out of stable - one for NXP 5.15.y and another for NXP 6.6.y, how are the torizon-containers doing it? Do they have an ARG on the Dockerfiles to make a distinction between versions at build time? Or are they just building a single container and shipping both versions of libraries, and things are sorted out at runtime?

[leonheldattoradex]

if two different base containers must be built out of stable - one for NXP 5.15.y and another for NXP 6.6.y, how are the torizon-containers doing it?

I think we're talking about different things here. When I say stable I mean our current stable. Regardless of whatever Debian has at the moment.

In the case of a bump from NXP 5.15.y to NXP 6.6.y for example, NXP 5.15.y becomes oldstable and NXP 6.6.y becomes stable.

As there are no breaking changes from the moment a stable release becomes oldstable, torizon-containers just bump minor/patch releases instead of majors.

We can also have oldoldstable etc...

[leograba]

I think we're talking about different things here. When I say stable I mean our current stable. Regardless of whatever Debian has at the moment.

So we adopt the terminology from Debian, but we don't match the releases. That sounds ok, and then we have one branch per Torizon OS major as well.

[escherstair]

I think now I understand.
The most important thing is that the meaning of the several branches is well documented in the README.md.
As a user, one of the most confusing thing I see when I start looking into a project that supports different branches at the same time is what is the purpose of the several branches.