AutoHotkey Community

It's more like a 3 in 1:

1. Display AHK's currently installed version.
2. Add a button or link to check for updates.
3. Possibly have the same button perform an in-place update or take the user to the download page.

As for 1, you can see installed versions by clicking Launch settings:

Marium0505 wrote: ↑

19 Sep 2023, 04:32

As for 1, you can see installed versions by clicking Launch settings:

Man I'm sorry, I saw your reply but forgot to answer at the time.
Thanks for the tip!
The suggestions stand, though

Display which installed version, where?

@lexikos I'm so sorry this topic went into a limbo in my "organized" reminders.
What I meant to suggest was something like this:

Again, display which version?

A supported (and perhaps common) scenario is to use v2.0 by default but v2.1-alpha for scripts that specify it with #Requires. In such a scenario, the user would likely want updates for either branch.

lexikos wrote: ↑

23 Jun 2023, 02:22

If you do not wish to run scripts with v2.1-alpha by default, ensure you have installed at least v2.0.3 the normal way, and change the v2 build preference in the launcher settings from 64-bit to 64-bit, <2.1- (or 32-bit if that's your preference). This can be done in the GUI by typing or pasting into the ComboBox. If a script #Requires AutoHotkey v2.1-alpha.1, it will still run with the alpha.

The following file tracks the latest minor version of each major version or branch.
https://www.autohotkey.com/download/versions.txt

A new version such as 2.1.0, 2.2-alpha or 3.0 may eventually appear in this file, which might interest the user even though the new version is not a direct replacement for an existing installed version.

@lexikos
Ah sorry, I see it now; I thought version 2.0.x was the mainstream, while 1.1.37.x was deprecated and maintained available for compatibility reasons and 2.1 and above only for testers and early adopters. So naturally I would "vote" for 2.0.x. But with that said, then I don't know what would be best, considering different users have different versions of choice.

To be clear, arbitrarily choosing one branch to check and display is not an answer that I would accept.

Perhaps update checks should not be performed by default, and the process of opting in should require the user to specify which branches they want checked (e.g. v2.0, v2.1 and future). In the event that there are updates available across multiple branches, the GUI should reflect that.