Update apktool.bat to properly handle minor decimal versions to find highest version#3913
Conversation
…ding highest version Fixed finding correct highest version in windows when minor version is more than one digit (e.g. 2.12.0). Formerly, 2.**.0 is parsed as less than 2.*.0 due to Windows batch limitation of handling only whole integers
|
I don't dev on Windows so might just have to take your word on it. Do you have any screenshots or proof of work to help ease my concern how this works? |
There was a problem hiding this comment.
Pull Request Overview
This PR fixes version comparison logic in the Windows batch script to properly handle multi-digit minor versions (e.g., 2.12.0) when selecting the highest version of apktool.jar. The previous implementation incorrectly treated version strings as simple string comparisons, causing issues when minor versions exceeded single digits.
- Replaces single-line version parsing with proper semantic version comparison
- Implements separate tracking of major, minor, and patch version components
- Adds proper version comparison logic that handles multi-digit version numbers correctly
| set "filename=%%~nF" | ||
|
|
||
| rem Extract version part (apktool-X.Y.Z) | ||
| for /f "tokens=2 delims=_-" %%A in ("!filename!") do ( |
There was a problem hiding this comment.
The delimiter parsing assumes a specific filename format with either underscore or hyphen separators. Consider adding validation to ensure the version extraction succeeds, as malformed filenames could cause the version parsing to fail silently.
|
thanks! |


Fixed finding correct highest version in windows when minor version is more than one digit (e.g. 2.12.0), where 12 is minor version. Formerly, 2.**.0 is parsed as less than 2.*.0 due to Windows batch limitation of handling only whole integers, so a folder having multiple apktool jars, would not use the latest if the minor version is more than one digit. Fixed now.