I feel your pain. Ideally all bug fixes in branch_8x would be backported to branch_8_4 and before releasing 8.5.0 we’d do a last 8.4.x release with all the fixes that’ll go into 8.5 but without the features - that woudl give a pretty stable version. But that’s not how it’s done in practice.
Right now the 8.4.1 release seems to be the most stable we have had for several releases. There are some 16 new bugfixes committed for 8.5 so far so you could examine that list and determine if any of those are show stoppers for you :) Jan > 30. jan. 2020 kl. 02:05 skrev Dave <hastings.recurs...@gmail.com>: > > 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 >>>
