Clarification on Commit Comment "GDAL v3.0.0+ with built-in COG support..."

[bixb0012]

The Commit comment from @Chamlika on Jul, 13, 2021 states:

GDAL v3.0.0+ with built-in COG support plus fixes/enhancements

The comment is straightforward enough, but what I am trying to understand is how that comment reconciles with the fact that EXEs under OptimizeRasters/GDAL/bin/ all show file version 2.3.3.98. I will admit I am not a regular GDAL user, but how does 2.3.3.98 equal 'v3.0.0+' ?

Apologies if I am missing the obvious.

[Chamlika]

@bixb0012 These OR GDAL binaries built from public GDAL source carry internal versioning that do not match to public GDAL version numbers and can have fixes/enhancements. @abhiataero

[bixb0012]

@Chamlika, thanks for the reply and clarification, it definitely helps. Determining/finding the public GDAL version numbers is simple enough, is there a way users can find the OR GDAL internal version from files installed on their machine.

I realize comments in GH give me an answer, or at least an idea of an answer, but I am looking for something that can be done with files already installed on local machine.

~CONTEXT: Although my question stands on its own, it may of helped to provide some context for why I am asking it, so I will provide that here.~

~I have run into an issue with some not-quite-middle-aged ArcGIS products (ArcGIS 10.7.x and ArcGIS 10.8.x) not reading MRFs with LERC compression and PIXEL interleaving. Products with new-ish GDAL libraries (> 3.0.0) seems to handle it fine but anything with GDAL 2.x libraries doesn't read it. That led me down a path of looking into GDAL libraries used by OR because I believe the group building the MRFs is using OR (but I am working to clarify with them specific workflow).~

Disregard context because I think it may be confusing the discussion more than clarifying it.

[Chamlika]

@bixb0012 The following is what could get for you from one of the GDAL builders for windows. FYI @abhiataero

" We regularly backport from upstream but our base version remains dependent on how close we are to upstream GDAL codebase and API. Right now, for Pro 3.0 release we are using GDAL 3.4 ABI even though we have more updates from upstream our branch remains close to GDAL 3.4. This is useful for users to use the correct API documentation for python and SDK. Since the comment in the issue mentioned 2.3.3, we will have all the features of 2.3.3 and more from upstream depending on features/fixes we backport. "

[bixb0012]

I understand that Pro is already using GDAL 3.x code. For example with Pro 2.9.2, the GDAL DLLs show a version of 3.3.0.25, and you just stated that will increment to 3.4.x with Pro 3.0.

Maybe my context confused the matter more than clarified it because I really am just focused on trying to understand versioning within compiled GDAL files with OptimizeRasters and not any other Esri products. Given all the GDAL DLLs under OptimizeRasters/GDAL/bin/gdalplugins/ show a version of 2.3.3.98, I am trying to figure out how an OR user would know that a bunch of upstream 3.x code is compiled in those DLLs by looking at the files installed by OptimizeRastersToolsSetup.exe.

[Chamlika]

@bixb0012 Windows GDAL builders have come back saying it'd be best to look at the (features) that are available with the OR released GDAL binaries than to compare with the version number reported. At least for now, the version numbers are never in sync with the publicly released versions.