But! If we don’t have people throwing a new release into production and finding real world problems we can’t trust that the current release problems will be exposed and then remedied, so it’s a double edged sword. I personally agree with staying a major version back, but that’s because it takes a long time to reindex another terabyte in combined indexes when a bug is found. However that’s not the norm, and I’m on an edge case where a full reindex is a few weeks or longer, if it was less than an a day or so I would be on 8.x
> On Jan 29, 2020, at 7:43 PM, Jeff <jeffx...@gmail.com> wrote: > > Thanks Shawn! Your answer is very helpful. Especially your note about > keeping up to date with the latest major version after a number of releases. > >> On Wed, Jan 29, 2020 at 6:35 PM Shawn Heisey <apa...@elyograg.org> wrote: >> >>> On 1/29/2020 11:24 AM, Jeff wrote: >>> Now, we are considering 8.2.0, 8.3.1, or 8.4.1 to use as they seem to be >>> stable. But it is hard to determine if we should be using the bleeding >> edge >>> or a few minor versions back since each of these includes many bug >> fixes. >>> It is unclear to me why some fixes get back-patched and why some are >>> released under new minor version changes (which include some hefty >>> improvements and features). >> >> <snip> >> >>> >>> To clarify, I am mostly asking for some clarity on which versions >> *should* >>> be used for a stable system and that we somehow can make it more clear in >>> the future. I am not trying to point the finger at specific bugs, but am >>> simply using them as examples as to why it is hard to determine a release >>> as stable. >>> >>> If anybody has insight on this, please let me know. >> >> My personal thought about any particular major version is that before >> using that version, it's a good idea to wait for a few releases, so that >> somebody braver than me can find the really big problems. >> >> If 8.x were still brand new, I'd run the latest version of 7.x. Since >> 8.x has had a number of releases, my current thought for a new >> deployment would be to run the latest version of 8.x. I would also plan >> on watching for new issues and being aggressive about upgrading to >> future 8.x versions. I would maintain a test environment to qualify >> those releases. >> >> All releases are called "stable". That is the intent with any release >> -- for it to be good enough for anyone to use in production. Sometimes >> we find problems after release. When a problem is noted, we almost >> always create a test that will alert us if that problem should resurface. >> >> What you refer to as "bleeding edge" is the master branch, and that >> branch is never used to create releases. >> >> Thanks, >> Shawn >>
