search

kelyvin / Google-Messages-For-Desktop

A "native-like" OS X, Windows, & Linux desktop app for Google Messages
https://www.messagesfordesktop.com/
364 stars 50 forks source link

Old build detect macOS #34

Closed Matgen84 closed 3 years ago

Matgen84 commented 3 years ago

Hi

Since today, I've Old build detected error (macOS)

Can you update the app, please

Capture d’écran 2021-03-17 à 14 10 08

kelyvin commented 3 years ago

Eee yikes. I will try to take a look at this over the weekend and get a build out that resolves this.

aayushus commented 3 years ago

@kelyvin any update on this?

kelyvin commented 3 years ago

@mercplus @Matgen84 Sorry for the delay on this. You can download the latest versions here: https://github.com/kelyvin/Google-Messages-For-Desktop/releases/tag/v1.3.0

Hope that fixes your issues!

ronjouch commented 3 years ago

Hi @kelyvin . Nativefier maintainer here, coming from https://github.com/nativefier/nativefier/issues/1131#issuecomment-812646988 and https://github.com/nativefier/nativefier/issues/1148 .

  1. Thanks for having addressed this 🙂.
  2. I stand by this feature; letting people browse the web on a crazy old Electron/Chrome is an undiscutably bad thing (for security foremost, and performance)...
  3. ... that being said, at time of adding the feature, I didn't think about "pre-packaged" apps like yours. I had in mind users building their apps on their own, and able to understand the "please upgrade & re-build" message we're throwing at them.

→ So, I think you should override the message to something more targeted, and understandable by your target audience, e.g. something like Google Messages for Desktop is out-of-date. Please download the latest version at https://www.messagesfordesktop.com/ . Maybe you also want to tweak OLD_BUILD_WARNING_THRESHOLD_DAYS to something slightly higher than the current value of 60 days (but not too high please, security is important).

Notes:

Does this all make sense? Any feedback/disagreement? Thanks.

kelyvin commented 3 years ago

Hi @ronjouch. I really appreciate you coming here and helping to shed light on the situation and for being so thorough with your suggestions. I also want to thank you for all your work on Nativefier to make it extremely simple for me to pre-package these apps for general audience usage. I originally started this pre-packaged project for my personal network to use, then I used it as a marketing experiment, and it kind of blew up from there.

I only half agree with your second point, but I respect your decision, so other than that there are no disagreements here. I am a library maintainer myself and know what it's like to step a day in your shoes, as well as the work you do to make everyone happy. I think the suggestions you made are reasonable.

As for feedback, I just have a question regarding your first bullet point (of wanting to avoid additional flags). Do you foresee a future of supporting configs, i.e. a way for me to just set up some config hooks to alter some of these nuanced options myself (or do you already support this and I'm just really bad at reading docs)?

Thanks!

ronjouch commented 3 years ago

@kelyvin thanks for the kind words 🙂.

I have a question regarding your first bullet point (of wanting to avoid additional flags). Do you foresee a future of supporting configs, i.e. a way for me to just set up some config hooks to alter some of these nuanced options myself (or do you already support this and I'm just really bad at reading docs)?

  1. Regarding the topic of auto-updates discussed here: in order to let you apply your packager tweaks without having to patch the JS, I could make OLD_BUILD_WARNING_THRESHOLD_DAYS and OLD_BUILD_WARNING_TEXT overridable via undocumented environment variables. (The intention being to limit expansion of docs & flags, and to not expose the threshold in the docs). 👍 / 👎 / other ideas?
  2. Besides the topic of auto-updates: any other examples of things you'd like to adjust, but cannot?
  3. Finally, maybe warning on builds older than 60 days was a little bit aggressive. I could agreeish with someone arguing that it's excessive to demand as frequent upgrades from Nativefier apps as you'd expect from a regular browser, given that a typical Nativefier app stays within a known "probably safe" (of course with caveats) site, with less wandering around the wildest parts of the web. I could bump the default to, say, 90 days. With the Chrome release schedule, this is two Chrome versions. Thoughts?
kelyvin commented 3 years ago

@ronjouch Sorry for the late response. Thanks for your reply!

Here are my thoughts on all of your points:

Regarding the topic of auto-updates discussed here: in order to let you apply your packager tweaks without having to patch the JS, I could make OLD_BUILD_WARNING_THRESHOLD_DAYS and OLD_BUILD_WARNING_TEXT overridable via undocumented environment variables. (The intention being to limit expansion of docs & flags, and to not expose the threshold in the docs). 👍 / 👎 / other ideas?

I think that'll work perfectly for me! As long as I have a "hook" and make it easy for me to customize without needing to dive into the code, that should do the trick.

Besides the topic of auto-updates: any other examples of things you'd like to adjust, but cannot?

Personally I can't think of anything right now. One of the reasons why I like Nativefier is that generates a cookie-cutter app with a simple CLI command. Any other additional features are potentially outside the scope of the project and may dive a bit too much into Electron configuration territory (e.g. being able to have a setting within the compiled app to enable/disable tray icons, etc.). Those would definitely be nice to have, but I wouldn't expect support for it.

Finally, maybe warning on builds older than 60 days was a little bit aggressive. I could agreeish with someone arguing that it's excessive to demand as frequent upgrades from Nativefier apps as you'd expect from a regular browser, given that a typical Nativefier app stays within a known "probably safe" (of course with caveats) site, with less wandering around the wildest parts of the web. I could bump the default to, say, 90 days. With the Chrome release schedule, this is two Chrome versions. Thoughts?

90 days (i.e. up to two browser versions) is a reasonable approach. But to be honest, 60 days is fine too. Honestly, 60 vs 90 days doesn't matter because this is more of a personal time-tracking problem. I just need to remind myself to update the apps. For this repo, I can probably set up a CI job or Github action to set up constant releases, which would probably solve 90% of the issues that get reported here.

ronjouch commented 3 years ago

@kelyvin alrighty. In freshly-released Nativefier 43.0.1,

  1. I bumped the threshold from 60 to 90 days, I like it better too, to not annoy too much my own users.
  2. You can now override the warning text in your builds with environment variable OLD_BUILD_WARNING_TEXT. It will be bundled in nativefier.json and preferred to the default message. See

https://github.com/nativefier/nativefier/blob/f64c05f735a4211cb1685b5cc0676db966aca785/src/build/prepareElectronApp.ts#L72-L77

and

https://github.com/nativefier/nativefier/blob/f64c05f735a4211cb1685b5cc0676db966aca785/app/src/main.ts#L231-L233

adambraun82 commented 2 years ago

@kelyvin seeing the old build error msg -- don't happen to have an update for this by chance? This app is awesome and allows better productivity while keeping in touch with my work/personal folks. Thank you for building it!

RealYHD commented 2 years ago

Hi, I'm still having this issue on Windows 11. I'm on version 1.3.0, although perhaps I'm misunderstanding something?

creampuffyness commented 2 years ago

I am also getting this issue on Windows 11, but not on a Windows 10 laptop running the same version.

Edit: I ended up using this link to rebuild it myself. No more errors.

https://medium.com/@jrejaud/desktop-version-of-android-messages-for-web-62892d9640fe

RealYHD commented 2 years ago

I am also getting this issue on Windows 11, but not on a Windows 10 laptop running the same version.

Edit: I ended up using this link to rebuild it myself. No more errors.

https://medium.com/@jrejaud/desktop-version-of-android-messages-for-web-62892d9640fe

Yeah, that's a good idea, I ended up using nativefier myself. Works well.

EDIT: Oh by the way, (you may already be aware of this and decided against it, it's not unreasonable) there does seem to be a boolean argument in nativefier that disables this error, in case that's something you want. --disable-old-build-warning-yesiknowitisinsecure If this repository should become a simple place for people who just want to easily be able download and run Google Messages, maybe this repository should set up some sort of automation where on a new version of chrome release, a simple nativefier script is ran to update the build? Then, the above flag can be used without as much worry (since I believe nativefier doesn't actually check version as much as it just checks how long since it was built).