[ben509]

I wasn't clear what's changing that is so problematic, so to summarize this post[1] and various comments: CentOS Stream will track ahead of RHEL and thus will be more like a beta channel, losing the stability guarantees that CentOS users depended on.

[1]: https://blog.centos.org/2020/12/future-is-centos-stream/

[arp242]

IMO CentOS stream isn't problematic as such, and neither is CentOS "classic" switching to stream; distros evolve all the time. The basic idea of stream seems like a decent one as such. Some may not like it, but that's okay. In my opinion, the problematic part is that the EOL date of CentOS 8, released last year, suddenly shifted from 2029 to 2021.

For years CentOS promised long-term stability and "boringness", which was its main selling point. A very long support cycle was its main selling point. It's why people installed CentOS, and now, suddenly, that's gone.

I don't think it matters that it's free in this case; they made a commitment/promise and suddenly went back on that. I wonder what all the sponsors[1] think of this; I'd be pretty darn peeved if I would sponsor something like CentOS, and it suddenly shifted direction like this.

[1]: https://www.centos.org/sponsors/

[masklinn]

Isn't Fedora already the RHEL upstream? Why not just kill CentOS entirely?

[dralley]

No, Fedora and CentOS Stream are very very different.

Fedora is where new and shiny lands, with a release schedule of every 6 months, and ~1 year of support per version, with minimal backporting of bugfixes and frequent package updates. Lots of packages (including the kernel) update freely. That would not fly in CentOS.

CentOS Stream is the next minor version of RHEL. There is lots of backporting patches, ABI stability, the works. And it is supported for as long as RHEL is supported (the standard tier anyways) because it is the next minor version of RHEL.

For a visual metaphor:

Fedora ---------------------------------------------> CentOS Stream --> RHEL

The development process works basically like this:

1) A new RHEL release is created from a rough snapshot of Fedora. It's not an exact copy of Fedora, a fair number of changes are made in the process.

2) Fedora keeps moving forwards quickly, RHEL stays put

3) CentOS Stream takes the most current RHEL release and starts layering updates on top of that

4) After a couple of months these updates from CentOS Stream are then pushed into RHEL as a new point release

5) Repeat steps 3 and 4

[dralley]

Or to put it another way, Fedora is (roughly, with caveats) the upstream for new major releases of RHEL, but CentOS Stream is upstream for minor releases of RHEL.

[denimnerd42]

Centos is going to be a beta for the next point release. Fedora is like next major version but I’m not sure if they actually fork Fedora to get that or if they just use it to preview the technology.

[jolmg]

s/fork Fedora/fork RHEL/ I imagine you meant.

[denimnerd42]

Fork fedora to be the new rhel version. maybe there’s a technically better way of describing that.

[jolmg]

I see. I understood "they" to be "fedora", so I thought you said "fedora forks fedora" i.e. "fork fedora to be the new fedora version". So, I thought you meant "fork RHEL to be the new fedora version". I see that's backwards now.

EDIT: "Fedora is like next major version" also adds to the confusion. If Fedora is like the next major version of RHEL, it makes sense that Fedora forks RHEL and not the other way around.

[pelasaco]

so will it be basic the same as openSUSE Tumbleweed for SUSE Linux?

[viccuad]

  Debian Unstable     -> Testing       -> Stable -> Oldstable -> Oldstable with LTS
  Fedora              -> Centos Stream -> RHEL   -> RHEL with LTS
  Opensuse Tumbleweed -> Leap          -> SLES   -> SLES with LTS

Debian supports upgrades with major versions, and doesn't bump package major versions between minor versions. SLE/Leap don't support upgrades between major versions, and bump package major versions between minor versions.

[pferde]

It is untrue that SLES does not support upgrades between major versions: https://documentation.suse.com/sles/15-SP2/single-html/SLES-...

It is, however, true that SLES is less conservative than e.g. RHEL when it comes to bumping software versions between their minor releases (service packs). I remember that they switched from 2.6 to 3.0 kernels sometimes in SLES10 days. Fun stuff.

[pelasaco]

openSUSE however doesn't support it https://en.opensuse.org/SDB:System_upgrade#Supported_scenari...

[pferde]

The link you posted only states that the upgrade is not supported for 64-bit ARM, and that 32-bit (x86) system cannot be upgraded to Leap. It doesn't say upgrade in general is not.

[merb]

tumbleweed does or rather, tumbleweed does not have point releases. in my eyes tumbleweed is way better for cloud, IoT and desktops, as soon as you use transactional-update

P.S. I'm fallen in love with it.

[rombert]

Note that the gap between Leap and SLE will become quite small after Leap 15.3, with binary packages for SLE being reused for Leap.

It's interesting that while RH/IBM are moving away from the 'community rebuild' model SUSE are moving close.

https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap

[pelasaco]

> Opensuse Tumbleweed -> Leap -> SLES -> SLES with LTS

Almost right :)

Leap is the fixed point release, based on SLE. SLE is rebased on Tumbleweed every 3-4 years.

[viccuad]

Well, my intent was to roughly chart the supported timeframe and expectations of each, not the flow of code through them. That SLE gets rebased from Tumbleweed directly every 3-4 years justs showcases my second point from before: SLE bumps major versions of packages between minor SLE versions.