QB64 Phoenix Edition v3.2.0 Released!

[mnrvovrfc]

I've always been reasonable in all my requests in the past but sometimes it was difficult to be understood (I'm still a native froggy)
With regard to the GitHub request, let me be more precise: Don't modify anything in the current process that creates a new place for each and every new release that is absolutely perfect, but just add a fixed place to store each new release always at the same place and always with the same name, so without any numbering version. I suggest the following simple names:
- https://github.com/QB64-Phoenix-Edition/...st.tar.bz2 for Linux, (please .tar.bz2 Vs .tar.gz for a 20% size gain)
- https://github.com/QB64-Phoenix-Edition/...st.tar.bz2 for macOS, (please .tar.bz2 Vs .tar.gz for a 20% size gain)
- https://github.com/QB64-Phoenix-Edition/...latest.Zip for Windows 32 bit (Please .Zip Vs .7z since 7z is not natively supported on multiple Windows release).
- https://github.com/QB64-Phoenix-Edition/...latest.Zip for Windows 64 bit (Please .Zip Vs .7z since 7z is not natively supported on multiple Windows release).
This would allow my script to download QB64PE automatically from GitHub without being obliged to modify
the script for each new release. This is why I host it on my own server.

"bz2" is even less supported than 7-zip, which could be a PITA on Linux if "p7zip" wasn't pre-installed with distro. "7z" is used for Windows package because that is already approaching 100MB with no easy way to cut it down. A lot was already taken away from MinGW, and even more functionality (such as device and language support) would have to be taken away that wouldn't please a lot of people. I suppose an archive could be made available which uses M$ Visual Studio's C++ compiler instead of "g++" but for the people willing to waste time and disk space with that programming system. Inventing that archive would have its own complications. ZIP is like WAV, widely supported and that's why it exists at all. ZIP is inherently very inefficient, a format carried way beyond its prime, it wasn't designed for files much larger than 10MB. So 7-Zip was created which retains some legacy features. What a shame RAR is closed source, but as of v5 the author might have been more interested in retaining the commercial customers: the recovery record could actually produce a larger RAR than v4 did!

If you are on Linux don't bother with "unrar-free" because it hasn't been updated in a really long time and cannot handle many RAR files. Definitely it cannot handle any RAR created by WinRAR v4 or later. I'm saying this because it's possible that "utility" is set as dependency of "winetricks".

I don't know nor care what is going on with Windows beyond Windows10 but M$ need to get out of their arse already, at least support "7z" for reading without requiring 7-Zip or WinRAR installed. Either that or support "tar.gz" or something like that without forcing the user to go into WSL or something else. There are a few other things that File Explorer can't do which cause it to lag behind "dolphin" for KDE Plasma which irritates me for other reasons (animations for starters).

EDIT: "latest", no thank you I'd rather know what is this "latest" version/release. "Latest" could be taken literally by somebody who uses "archive-dot-org" to obtain such a ZIP file because he/she could do so. A "latest" could be hosted on somebody else's server and left there for a long time for download, and there are just too many of those bad people to compete with.