Community
Select to view content in your preferred language

I'm getting confused by the Esri approach to bug fixing.

296
4
a week ago
RTPL_AU
by
Honored Contributor
a week ago

I was going through the currently listed bugs for Pro 3.5/3.5.1 and found this one that will be fixed in 3.6.

 

RTPL_AU_0-1749167958611.png

 

Knowing that our State is migrating to Parcel Fabric, it made me wonder about the approach to keep fixing bugs in the next version of Pro rather than the one the bug was found in. I felt it became more prevalent in 3.4 which had a few niggles, that were fixed in 3.5, which then introduces its own new bugs.

As Pro point versions seem to be quite unstable currently (from a *nix feature change perspective, not just 'it may crash'), it is getting quite hard to plan processes & workflows from a long term point of view. 

You can spend time/money to streamline a workflow in a specific version but then run into a showstopper bug.
What do you do now? A new version comes out that fixes the bug but also introduces a shiny new feature that replaces part of your process in a way that you cannot incorporate without re-doing a lot of work. 
This is aside from the potential for significant bugs in the X.Y.0 version. 


How valid is it to think that the release model should change to a mix of Long Term Stable + New Feature Releases Short Term Unstable?

If you think it has merit please upvote the Idea:
https://community.esri.com/t5/arcgis-pro-ideas/change-pro-development-to-use-a-more-conservative/idi...

 

 

4 Replies
MarcoBoeringa
by MVP Alum
MVP Alum
a week ago

I totally agree this approach of only "fixing" issues in new releases is highly problematic. In my opinion, a bug is only truly "fixed" if the fix is backported to the release cycle where the issue / bug was first introduced. Fixing issues only in new releases is "addressing" the issue, not fixing it.

A fix for an issue / bug introduced into e.g. 3.4.0, should not require upgrading to 3.5 or 3.6, but should be addressed in a 3.4.x minor bugfix release.

MarcoBoeringa
by MVP Alum
MVP Alum
a week ago
@RTPL_AU wrote:

How valid is it to think that the release model should change to a mix of Long Term Stable + New Feature Releases Short Term Unstable?

Introducing such Long Term Stable releases would only be a viable approach if the LTS release is actually actively maintained and being worked on with additional (backported) bugfixes. If it is just another unmaintained essentially dead release cycle nobody cares about, it would solve nothing.

0 Kudos
RTPL_AU
by
Honored Contributor
a week ago

To add more context - there is the Pro Life Cycle information.  I'm just confused by the walking, talking & chewing at the same time vs the doing what they say they are doing.

https://support.esri.com/en-us/products/arcgis-pro/life-cycle

 

0 Kudos
MarcoBoeringa
by MVP Alum
MVP Alum
a week ago

About the life cycle: to me, any(!) bug and a fix for it that is detected in any of the current "general availability" major versions (which is generally the last three major releases, e.g. 3.3, 3.4 and 3.5) should be automatically applied and / or backported to all the other major releases in "general availability" if it is also applicable to those other major versions (there maybe cases where it is not, e.g. if the issue is only related to new functionality not available in lower versions).

Currently, this is not the case, and ESRI seems to apply a highly opaque "vetting" system for backporting fixes that feels essentially random to Pro users, and only true security issues seem to automatically make their way to lower versions.