Make updatechecker plugin for MacOS

[rovf]

Sadly, Geany has no builtin way to check for updates. It would be great to have an updatechecker plugin for MacOS, similar to the one for Linux and Windows.

[elextr]

The update checker for Linux works incorrectly, it checks the Geany repository for a new version, not the repositories for the current distro. Most distros don't update versions of software like Geany on LTS versions for example. So it just feeds frustration for users of such systems as they see Geany has released a new version but its not in their repository.

Its really only useful for Windows, but maybe it could be made useful for Macos if it looked at the right repository because it can get new bugfix releases separate from Geany.

[techee]

See geany/geany-osx#53 (comment)

[eht16]

The update checker for Linux works incorrectly, it checks the Geany repository for a new version, not the repositories for the current distro. Most distros don't update versions of software like Geany on LTS versions for example. So it just feeds frustration for users of such

I'd say it depends on the user. There is maybe a minority of users who compile Geany themselves from release tarballs and for those the plugin might be useful.

Its really only useful for Windows, but maybe it could be made useful for Macos if it looked at the right repository because it can get new bugfix releases separate from Geany.

Isn't the plugin for Macos in the same way useful as for Windows as it checks geany.org for the latest version and this is where the Macos version is distributed.
AFAIK Geany is not mainly distributed via some sort of repository like "brew" or so but via downloadable installers from our website and so I thought the update checker plugin would do the same job on Macos as on Windows.

[elextr]

AFAIK Geany is not mainly distributed via some sort of repository like "brew" or so but via downloadable installers from our website and so I thought the update checker plugin would do the same job on Macos as on Windows.

I thought I had seen @techee make bugfix builds on the geany-osx repository, I guess if they get uploaded to the Geany website that would be ok, but then whats their version, if its the same then the update checker won't notice?

[elextr]

Just to note what the expectation of many users may be, both Chrome browser and Vscode IDE update checkers indicate a new version in app, and when triggered to update can indicate if its available by an "alternate channel" which means the distro normal update mechanism rather than direct from Google/MS source repo. Don't know how they do that, but maybe its in the open source parts of those apps?

Edit: both apps have added an additional package repository to sources.list so thats how they know and can get updated when the distro updates. I guess that unless it can be totally automated we don't have the resources to support that.

[techee]

I managed to get the update checker plugin running (didn't really do anything, it started working with the latest library versions from gtk-osx). So I might add it to the next macOS release.

I thought I had seen @techee make bugfix builds on the geany-osx repository, I guess if they get uploaded to the Geany website that would be ok, but then whats their version, if its the same then the update checker won't notice?

The URL

https://geany.org/service/version/

which the plugin uses only returns the latest Geany release version and not the actual build. I was forced to make a new macOS release when e.g. a new macOS release broke something in GTK and I needed to re-package the release with the latest GTK libraries containing the fix. Geany itself was the same though so the update checker wouldn't see such a change.

What I could imagine we could do is to send the current version and the build date to the server (which can be seen on the About page of Geany, such as built on or after 2024-06-21) and I think it would actually be best to leave the whole logic of whether the update is available or not on the server - it would just return TRUE or FALSE based on the info we send from the plugin. This would probably require a new URL, such as https://geany.org/service/version/v2.

[elextr]

probably require a new URL, such as https://geany.org/service/version/v2.

Yeah, then it can reply:

2.1.0
Macos 2.1.0.1
Windows 2.0.0.5555

so then Mac and Windows fixes can be uploaded separately. (the first is latest release tagged in Git/tarballed, it can't be "Linux" because we don't supply that download)

And as shown Mac/Win can be behind, so its not necessary to get everybody and their pet dog available at the same time for a release.

[techee]

Yeah, then it can reply:
2.1.0
Macos 2.1.0.1
Windows 2.0.0.5555

I was actually thinking the plugin would send e.g.

platform: macOS
version: 2.0.0
build_date: 2024-06-21

and the server would only reply TRUE or FALSE based on whether the update is available for the given platform, version and date. Having the whole logic on the server would allow us stop update notifications e.g. if we made some buggy release and didn't want users to update to it.

[elextr]

I was avoiding having any smarts in the server, just have it return a file, which could even be served from github. If we don't want a new release to be used we just don't put the number in the file. And that way you can modify the Mac version without any server support by PRing the file.

But I guess it depends on the infrastructure manager as to what smarts can be in the server and what they see as the best way for ongoing support.

[techee]

My thinking is that if we make a bug in the plugin's update logic, we'll have to make a new release to fix it while we can update the server's code any time without any release and it also offers more flexibility in case we need to change something in the future.

[elextr]

Well since the plugin is really only any use for Mac and Windows since we don't make any *x releases I guess its between you and @eht16 who conveniently is the infrastructure manager too :-)

[elextr]

Maybe make it a TOML file (see geany/geany#1268) 😈

[eht16]

My thinking is that if we make a bug in the plugin's update logic, we'll have to make a new release to fix it while we can update the server's code any time without any release and it also offers more flexibility in case we need to change something in the future.

This is a good point.

Still, I think it would be best to let the plugin decide whether to update or not.
But we can definetely improve the server response and provide more information, e.g. like suggested in #1314 (comment) but as response instead of request.

Having the logic in the plugin would not require to send any information to the server and so be more privacy friendly.

[techee]

@eht16 OK (especially if you plan to have the Geany web site static).

For macOS and Windows we'd have to decide how to detect the updated installer - let's say I make a new macOS release now with updated GTK fixing some bug - the version will still be 2.0 and the only other thing I see we could use for update detection is the build date and compare it with the date from https://download.geany.org which the server could send. But it seems a little fragile and we'd have to make sure we set the installer date to the same date as the build date of Geany inside the installer.

[elextr]

@techee if you release a bugfix maybe you need to version it 2.0-1 like Ubuntu does with its packages. Not sure it the plugin needs updating to handle that.

[techee]

@techee if you release a bugfix maybe you need to version it 2.0-1 like Ubuntu does with its packages. Not sure it the plugin needs updating to handle that.

Yes, but how to get this version "inside" the package so the updatechecker plugin knows it's 2.0-1 and can compare it with what the server returns as the latest version? From the code point of view the Geany version will still be 2.0.

[eht16]

@eht16 OK (especially if you plan to have the Geany web site static).

I guess we will keep a small Django site anyway for the Pastebin service and even if not this won't be the problem.

@techee if you release a bugfix maybe you need to version it 2.0-1 like Ubuntu does with its packages. Not sure it the plugin needs updating to handle that.

Uhh, don't tell this the Debian/Ubuntu guys :). They use the -1 suffix for package versions of the same upstream version.

Yes, but how to get this version "inside" the package so the updatechecker plugin knows it's 2.0-1 and can compare it with what the server returns as the latest version? From the code point of view the Geany version will still be 2.0.

We could bake something like a "build number" or so into Geany which starts with 1 for every version and for rebuilds (like in your example) could then have the build number increased. The plugin will check the version number and the build number together. The server sends then the version and the build number to the plugin. We don't need to extract those information from the installer file, it could be managed seperately with a simple web interface on the server or just a file. Less convenient but also less fragile :D. Thinking this further, for such cases when we update the installer for an existing version, we probably should also make this clear to the user, e.g. also show the build number in the plugin notification dialog.