search

majkinetor / au

Chocolatey Automatic Package Updater Module
GNU General Public License v2.0
227 stars 71 forks source link

How to handle different 32/64-bit patch versions that are technically the same parent "version" #270

Closed sumo300 closed 1 year ago

sumo300 commented 1 year ago

How is it recommended to handle when the 32 and 64-bit versions of a "release" are technically different in the "patch" section of the version number (i.e. 1.2.38 vs. 1.2.35) and the organization publishing the release treats them as the same version?

This is more of a question, than an issue and requires a real world example to explain the question.

For my org, I have created a portable version of Azul Zulu 11 JRE LTS and have made assumptions that the release versions for 32/64-bit are identical. However, Azul at times has releases that are for the same Java version, but one edition (32/64-bit) is patched that is not applicable to the other (i.e. a 64-bit fix that is not applicable for 32-bit). At a high level, Azul treats it as the same release due to their requirements of only Major.Minor needing to be the same to treat it as the same release.

The current latest version of Azul Zulu 11 JRE LTS is a perfect example.

The Java version this release is for targets 11.0.16.1+1, but 32-bit has 11.58.25 as its version and 64-bit has 11.58.23 as its version. This affects the file names of the releases and AU, when used in typical cases, sees the first version (in this case 32-bit) and uses it for the 64-bit as well since the package includes both 32/64-bit downloads.

Is handling this really just one of these two scenarios:

  1. Treat them as separate packages?
  2. Write code in update.ps1 that looks at the latest release, takes the higher of the two versions, and then bundles the links to the downloads as they are rather than building the URL using the version # variable?

Are there other options?

majkinetor commented 1 year ago

This is more a question for a chocolatey guys.

IMO, if you are 100% sure that x64 version always follow x32 version, you could use x32 version for both and add a note in package.

When I had that problem I abandoned update until the versions match but, the vendor didn't treat different patch versions as the same but it was due to bad vendor release practices.