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.
Rig
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
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 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
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
TL;DR: I am having difficulty on deciding on a release that is stable to
use and would like this to be easier.
Recently it has been rather difficult to figure out what release to use
based on its stability. This is probably in part because of the rapid
release cadence and also the versioning being
