> > Given we are not developing drivers or applications (other than websites > and web applications), is the change a non-issue for my use-case? I've seen > it written that CentOS Stream is the "development version" of RHEL but also > that we shouldn't have considered RHEL to be the beta for CentOS. Others > have said to think of CentOS more like RHEL RC-1. I just don't know how the > stability will compare and we have historically always chosen CentOS for > its stability (and of course price). There's been a lot of information and mis-information being bandied around on websites from people who don't really quite understand what's going on. I hope I don't contribute to the confusion! It wasn't helped by the, frankly, heavy-handed way it was handled by RH. One of the problems is that people are trying to put a label on what 8- stream is - such as development version, or RC, or beta version or whatever. To be honest all we can do is to try and understand what RH want. As far as I understand it, 8-stream accumulates new versions of packages that will collectively go to make up the next point release of RHEL8. We have been told, and we can only take it at face value, that the versions that go into 8-stream will be final, QC'd packages: they are not test, development or beta versions, nor are they "work in progress". 8-stream will be a complete and functioning, stable distro. So rather than waiting to get the new versions of things once every 6 months, 8-stream gets them when they are ready. The confusion about the "development" label is that RH said that 8- stream will be the distro used for their development process. So internally things will be developed and compiled in an 8-stream environment. They have never said that the development packages will ever be visible or available in 8-stream itself until they are ready to be set free. TBH I would have thought that this exactly how RH operate internally at the moment - they must have, say, a pre-8.3 environment that they put packages in so that when new packages are developed that can be compiled and everything is compatible. I really can't imagine that packages are developed in isolation until there's a big 8.3 compile time. All they are doing is making that internal system a public thing. Now it's certainly possible that from RH point of view, releasing the packages into the wild is a very good way of finding bugs that might have slipped through QC - there is after all already a steady stream of updates between point releases. So the benefit for RH is that paying customers get potentially fewer updates between releases, but the implication is that 8-stream will be no less stable than CentOS 8 currently is. The rhetoric from RH is that the tooling of the 8-stream system is not fully in place yet, but should be soon. Again, we can only take them at their word and watch what happens. And I must stress that I am no RH apologist: I think it was all handled incredibly badly by them and they desperately need to get some change management experience!! If you are considering using 8-stream then you need to understand that there is no specific point-release configuration that you can base things on - you cann't say that this is "equivalent to RHEL 8.5" or whatever; this is important if you need to use 3rd party drivers during install as they are based on specific configurations (but hey, install CentOS 8.2 and move to 8-stream from there and upgrade). Also the lifetime of 8-stream is half what you've been used to - so come 2024, it will die; but 9-stream will have existed for at least a couple of years by then, so there is a roadmap. As for what you should do, than no one can really tell you. My advice to others has been to watch, evaluate, test. If you are running bog standard web servers with nothing exotic, then I have a feeling that 8- stream will work; if you are running 3rd party apps on a web service where versions matter, then you need to think carefully and consider switching to one of the rebuild distros. > > Of course, a lot of this is somewhat dependent on what DigitalOcean will > decide to provide image wise moving forward. I suspect that as more and more things become containerised (and boy do I dislike containers), the actual underlying OS will become considerably less important. P.