search

ferdium / ferdium-app

All your services in one place, built by the community
https://ferdium.org
Apache License 2.0
2.88k stars 173 forks source link

Feature: Show release / changelog notes prior to triggering an update if a user clicks the update option when a new update is available #487

Closed ylluminate closed 2 years ago

ylluminate commented 2 years ago

Preflight Checklist

Problem Description

Currently it seems that with "Enable updates" and "Include pre-releases" enabled that it is very easy to accidentally be unaware of a change, problem or something else.

Proposed Solution

If there were a method to show the release notes / changelog prior to the user accepting to actually install an update, that might be good insomuch that it will act as a warning and/or make users aware of what to expect (such as the last update that included the horizontal bar change and requirement to toggle off and on).

Another thing that may be useful would be to, instead of - with PRE-RELEASE ONLY - triggering an auto-update, perhaps require the user to click the "Check for updates" function (eg, on macOS under menubar: Ferdium → Check for updates) to use more awareness and thoughtfulness before blasting in an update...

Alternatives Considered

Another choice, that wouldn't get as much testing for the (auto)update system would be to just force manual updates for pre-release vs allowing users to just trigger it.

Yet another choice would be, in the same manual line as above, when they click auto-update function on the bottom popup updater bar, it would lead them over to the releases page to be forced to have the release notes more readily available.

Additional Information

No response

meiphoo7-Mae commented 2 years ago

I'm in favor of part of the proposed solution. I don't install all pre-releases as some of them contain features or fixes I'm not particularly interested in at that moment. However I use the AppImage and regardless of what my decision will be the updater downloads the update (100+ MB) anyway, stores it somewhere and shows in the updater bar at the bottom a message there's an update available. If I decide to install it the downloaded file is copied to the permanent location otherwise it isn't. So every now and then the updater downloads a file that I'm not going to use. I like that the updater detects new files but I would prefer, as the proposal suggests, that the updater waits for user confirmation to actually download it. Forcefully showing the release notes is something I do care less about as I'm already reading them before deciding to install an update.

SpecialAro commented 2 years ago

Hi!

I'm currently working on this issue, but there are some things that still need working to fully address all requests.

As it is now, the app will download the file, regardless of the user decision (kinda the user decision because it has Enable Updates on) and will show a changelog button before installing... This will allow the user to see the changelog prior to install it.

Please check this video to see if this is what you want 😁

https://imgur.com/a/6U1RJu9

Note that only the changelog of the version which is going to be installed is shown (not showing the changelog in between the actual version and the version to be installed - as it happens in all other app updates)

ylluminate commented 2 years ago

Thank you so much @SpecialAro for sharing that video. Unfortunately, for me, I was unable to see the text / details of what you were attempting to illustrate in that screencast. It was too blurry and too light to make out the details...

Really appreciate your working on this to help facilitate more cautious / judicial nightly updating.

meiphoo7-Mae commented 2 years ago

Yes, I agree. I viewed it on a rather large screen and I can't make out any details either. But I assume we'll see the results soon in real life. and... No, I don't agree that enabling updates constitutes a user decision to download any update that is available. Probably in the era of Windows 95 it was but that time is a long time ago. AFAIC enabling updates means that I'll get a notification of any updates available. And no automatic download results in less internet traffic on the server.

That being said I certainly don't want to start a (nasty) discussion about this and I certainly do want to thank all the contributors for the impressive amount of effort they put in this project. We're currently at nightly 101 so that means on average a new version is released every other day if I'm correct.

vraravam commented 2 years ago

@meiphoo7-Mae - unfortunately, electron (which is the framework that Ferdium is built on top of) does not support what you are asking for: https://www.electronjs.org/docs/latest/api/auto-updater#event-update-available

meiphoo7-Mae commented 2 years ago

@vraravam OK, that's something I actually didn't think of. Thanks for pointing this out.

I noticed you have removed two labels and added one about upstream dependency: may I politely remind you that I didn't open the issue (but actually hijacked it a bit) and that the initial feature request of @ylluminate is worked upon by @SpecialAro as stated earlier in this thread? Are you sure reassigning the labels is the appropriate choice?

vraravam commented 2 years ago

@meiphoo7-Mae - 1) please do not hijack tickets 2) Yes - i knew that, but i also know that @SpecialAro has implemented some code in his branch - which was waiting for this functionality. Imo, the original ticket's asks will be addressed by his upcoming PR. Since the original requirements are over (waiting for the PR), I removed the "good first issue" and added the "upstream dependency". If you can create a new ticket for those pieces that you had wanted, we can move that upstream dependency tag to yours and remove from this one. That way, we can cleanly close this ticket.

meiphoo7-Mae commented 2 years ago

Well, I didn't really hijacked the ticket of course, but added some thoughts to it. The initial request was that the updater makes it is for user to install pre-releases without reading the release notes. I only added that the updater automatically downloads huge updates without user confirmation (thereby also enabling installing pre-releases without reading the release notes).

You provided a link to a webpage pointing out that what I suggested (only a notification of an update and not immediately downloading it) is not possible. So that's a clear answer. I don't think it is necessary that I'm going to open a new issue about this (but if you feel it is useful, I can open a new issue if you like. Please let me know.).

If you think this is the right moment to close this issue, please proceed with that.

SpecialAro commented 2 years ago

@meiphoo7-Mae - unfortunately, electron (which is the framework that Ferdium is built on top of) does not support what you are asking for: https://www.electronjs.org/docs/latest/api/auto-updater#event-update-available

There might be a way of, at least, prevent users for getting the pop-up to install and everything... Haven't tested it yet, tho.

https://github.com/ferdium/ferdium-app/blob/b85efe342e727905eb227bf227a9d1f06ae48e79/src/electron/ipc-api/autoUpdate.ts#L46-L55

This can be useful but I'm not entirely sure we can tell the auto-updater from electron to not download. What, instead, we can do is set a button for "manual updates" so that the user needs to manually go and click to start the Update process, and we can try to implement a button for "Skipping or Don't install" a version - after fetching an update. Tho, I don't think this can be useful, given that we want users to update (good practice)... and a user should also wan't to update as soon as an update is available.

If there are concerns about stability on nightly branches, then a user should activate Pre-releases - even though I'm for implementing a button for "nightlies" and one for "beta", filtering Pre-releases.

meiphoo7-Mae commented 2 years ago

@SpecialAro Thanks. That sounds good to me. Skipping a version is already possible to a certain extent by dismissing the blue bar. However for some reason this works only temporary because in the end the blue bar shows up again. Is it necessary or useful to open a new issue ticket for this, that way this issue can be closed cleanly as suggested by @vraravam, or is it going to be solved anyway by your pull request?