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
