idea Change Pro development to use a more conservative release stream approach in ArcGIS Pro Ideas

Change Pro development to use a more conservative release stream approach

RTPL_AU — Fri, 11 Oct 2024 01:39:35 GMT

Many software solutions or operating systems are developed using a release stream approach that caters to the end user appetite for features balanced with stability.

Ubuntu (a Linux distribution) has half yearly feature releases with a Long Term Support (LTS) version every two years.
The LTS versions are maintained for 10 years and the frequent releases for ~9 months.

Debian uses a multi-tiered approach with Stable, Testing, Unstable, & Experimental. Simply put - Stable is current (and conservative), Testing is 'next stable' and pretty solid with many latest features, and the other two are likely to break at any moment and render your system unusable (for a few minutes until you fix it... 🙂 )

On the flip side you have full rolling release approaches where you never have a 'point in time' release but get every new feature as it comes along. Yes. I use Arch. Occasionally.....

ArcGIS Pro seems to be leaning too far into the rolling release approach, in my opinion. There are major versions, but these are only based on a feature weight approach with no further support expected to be given once the next major version is released.

My request is that Esri change the release cycle of Pro to be more in line with the Ubuntu approach where we, as paying customers and, currently, unpaid beta testers, can decide if we want to be on the 'give me the latest' bullet train or stick with a stable Camry version that will continue to receive bug fixes and security patches for a defined long period of time.

I hope that some of the bugs in 3.3.x will get fixed but I am afraid of the issues that we are bound to find in 3.4 due to all the new great things it will be able to do, allegedly.

Re: Change Pro development to use a more conservative release stream approach

RichardDaniels — Fri, 06 Jun 2025 16:21:50 GMT

If the ArcGIS Pro version is in General Availability phase, then all significant bugs should be addressed per Esri Product Life Cycle Policy dated January 2025. A field calculation error that can result in data corruption is a big deal and will be addressed in all versions of the application currently under support. In this case this error (BUG-000176644) was introduced with ArcGIS Pro 3.5 and addressed with SP 1. the error does not exist in ArcGIS Pro 3.3 or 3.4.

Software patches or hot fixes
o Provided to customers to resolve significant issues discovered in the product
release.

• New environment certification
o When a major new version of an environment is released during the General
Availability phase of an Esri product, Esri will test this new environment with the
Esri software product in its General Availability phase and provide updated
system requirements.

Re: Change Pro development to use a more conservative release stream approach

RTPL_AU — Fri, 06 Jun 2025 23:25:45 GMT

@RichardDaniels

I've read the policy and my key take-away is that Esri still determines what classification is applied to a product, and, more importantly, the classification of a fix/bug/enhancement/Idea.
It feels as if many bugs, if not 'significant' enough, get bumped into the 'it's an enhancement thereby fine for the next version' rather than getting fixed in the version it occurred.

The invasive license checking bug found in 3.3 was only ~~fixed~~ improved in 3.5, so any organisation on an earlier version will have to eat the productivity loss until they are ready to upgrade.

It would read better if they called it a guideline rather than policy.

Re: Change Pro development to use a more conservative release stream approach

RTPL_AU — Sat, 14 Jun 2025 07:47:14 GMT

I see Nvidia has this approach for their 'Professional' drivers.
Three streams is a bit much in my view, but I agree with the terminology.

Re: Change Pro development to use a more conservative release stream approach

xinyuxiao — Fri, 05 Dec 2025 06:12:41 GMT

Yes, I support this release method. Now, it seems that there are more and more bugs in the new version of ArcGIS Pro.

Re: Change Pro development to use a more conservative release stream approach

RTPL_AU — Sat, 06 Dec 2025 22:27:00 GMT

Words cannot describe the feeling when you reflect on something you said a year ago and it has aged like fine wine.

Re: Change Pro development to use a more conservative release stream approach

DEWright_CA — Sun, 07 Dec 2025 03:44:31 GMT

Add to that the ability to have more than 1 version installed; in this case the 3.5.x Long-Term release and the 3.6 Short-Term release.

ESRI releases versions of Pro that match-up with the version of Enterprise and it would be ideal to be able to have both installed on the same machine to test/compare both versions.

Re: Change Pro development to use a more conservative release stream approach

RTPL_AU — Sun, 07 Dec 2025 23:21:59 GMT

@DEWright_CA

Please make sure to Kudo the Idea to have multiple versions installed:

https://community.esri.com/t5/arcgis-pro-ideas/allow-for-multiple-versions-of-arcgis-pro/idc-p/1595041#M34115

My Idea of using a containerised approach was merged into this one although it has a unique component to it. A container based deployment would mean that all required add-ins, libraries, dependencies, etc are included in the container rather than having a very messy Windows environment.