On Mon, Dec 21, 2020 at 4:18 PM Gordon Messmer <gordon.messmer at gmail.com> wrote: > On the other hand, it is theoretically possible that bugs will be found > through real-world testing after release. At this point, I think it's > all but explicit that some of the most vocal objectors view all software > as a "beta" until someone else has used it for some period of time. For > those people, the value of the point releases is that they believe they > can reasonably expect to wait for an arbitrary period after a point > release to let other users work out the bugs. Rather than testing > software themselves, they're relying on the broader community to deploy > software and report bugs. To be clear, though, there's no evidence that > doing so is necessary or effective. If it were, we'd expect to see a > flurry of fixes for bugs that were introduced BY the point release after > each point release. I can't speak for all vocal objectors - but that's not it for me. I am happy to test. That's why I use Fedora as my home system, and even in certain production use cases, such as containers that run particular applications. We catch problems all the time. CentOS 8 Stream is a great opportunity to test. But what I'm testing with, is not what I send out to thousands of machines that are being used for production purposes to build product. If minor releases cease to exist, we will be forced to develop our own in-house minor releases. Which is not an insurmountable problem - we already do to it a degree. But, the bigger problem is in agreement on what those minor releases are. Without milestones to build against, and certify against, there is also no option except to upgrade to latest. For example, if Vendor X builds something in Jan, 2021, what happens if some daily update comes down the pipeline that breaks the Vendor X build, and our production use case stops working? Now, imagine Vendor Y builds something in Jan, 2022 that requires latest. But, we can't upgrade to latest because this breaks Vendor X. Now multiple this by 1000 different tools and tool versions. We have internal product releases that were last built in 2016, or 2008, or even 1999, that would take a substantial amount of money to update to work on latest releases. Today, we can do this by running older releases. Without these baselines, this becomes "not possible". It's fundamentally the same problem as the buildroot problem for 100% perfect reproduction of RPM, but extended beyond RPM to using EL as a development platform. We encourage users to use versioned tool chains, and containers to control this, and buildroots have been used in the past - but the existence of tools such as "gcc" and "make" in the PATH basically have the natural consequence that somewhere in the build process it is relying on the native tools, and upgrades break builds. I can appreciate that you are not aware of this problem - or perhaps you don't agree with the problem, and think that it should not exist. But, it's not correct to over-simplify the problem space. Versioning of products exists for important reasons. Whether a distro can or should be versioned, including minor versions, depends upon the requirements. Clearly, your requirements don't align with mine - and you are ok with results that I am not allowed to be ok with. -- Mark Mielke <mark.mielke at gmail.com>