Cura: Update Cura from within application

[Austinthemighty]

We need a way of checking and updating cura from inside cura itself. It is a pain in the ass to go to ultimakers website and download, uninstall and reinstall cura ever time there is an update.

[fieldOfView]

That would be nice, but also non-trivial. Updating executables while they are running can be tricky, depending on the platform.

[Ghostkeeper]

On Windows it could download the installer and run it. It'll ask the user to close Cura in the initial pages of the installer's wizard.

On Linux, there's the matter of where the AppImage file should be placed. If the file is placed it could theoretically close itself and start the new application.

On MacOS there's a similar problem of Linux but the location is clear (Applications). However the name of the file isn't. There's also the matter of file rights (also on Linux).

[probonopd]

Check AppImageUpdate for delta binary updates (i.e., only the bytes that have actually changed need to be downloaded). linuxdeployqt has a command line option to embed the necessary update information into the AppImage file. Let me know if you are interested and need more information.

[nallath]

I think it would be best to have an uniform solution for all operating systems. Otherwise we will have to design multiple systems, which will lead to a lot of overhead.

[awhiemstra]

There isn't one. The way things are installed are so completely different that we would need to create some kind of new cross-platform tool to handle it.

Basically, you need to do the following on different platforms:

• On Windows, download the new installer, run it, then in the installer make sure to close Cura during the install. This is mostly doable but requires some trickery with ensuring Cura is not running.
• On Linux, either just download the new AppImage and tell the user where it is located, or use the AppImageUpdate functionality.
• On OSX, download the new DMG and tell the user where it is located. In theory we might be able to do something with updating the actual App bundle but I do not know enough about OSX and security to be comfortable with that. Note also that you cannot just assume it is installed to /Applications since the user might just have installed it to his local files. The Application dir is just a convention, basically.

So I think the only "standard" thing we can distill from this is to have Cura perform the download of the new version. Whatever comes after that is platform-specific.

[fieldOfView]

If that means we can skip the survey, I am all for it ;)

[UltimateSports]

Even if it were a checker system that would inform you when there was an updated version on the website to download! too often i will continue using the one I have now for weeks after there is something new on the website.

[nallath]

That's because we tend to forget to update the number :$

[Ghostkeeper]

There is a system that checks for updates on the site and notifies you in Cura. I thought that works, right?

[UltimateSports]

possibly, how frequently are there updates released for the beta version? as cura still says its 2.5.0, and i didn't get a message about the 2.5.1 update which i noticed on the website when i checked out of curiosity after your comment.

[fieldOfView]

There is no 2.5.0 yet. There's a 2.5.0 beta and a 2.5.0 beta 2. I don't think the betas are included in the update system.

[UltimateSports]

Sorry, I missed the bit about the beta as i assumed we were referring to the beta versions. surely numbering would make more sense if instead of using 2.5.0 _BETA 2_ using _"2.5.1 Beta" or "Beata 2.5.1"_ ?

[Ghostkeeper]

We number our releases as 2.3.0, 2.3.1, 2.3.2, 2.4.0, 2.5.0, etc...

For each of the minor releases (ending in .0) we release a number of beta versions so that people can preview the changes and help us testing them. We just released the second beta for the 2.5.0 version, so we call it 2.5 beta 2.

The automated update checker doesn't check for beta versions. They are not meant to be entirely stable. The automated update checker does check for patch versions (ending in .1, .2, etc.)

[awhiemstra]

I'd like to include support for "update channels" at some point in the future where you can indicate that you'd like to run nightly/beta/stable versions and get update notifications for that. But it will be a while before that shows up.

Sorry, I missed the bit about the beta as i assumed we were referring to the beta versions. surely numbering would make more sense if instead of using 2.5.0 BETA 2 using "2.5.1 Beta" or "Beata 2.5.1" ?

The current beta is the second beta release for what eventually will become the 2.5.0 release. Calling it 2.5.1 beta would mean it is the beta release for what will become the 2.5.1 version.

[UltimateSports]

ok, that makes more sense, thanks for clarification. but comment about update checker would still be appreciated for beta versions if this would be a possibility in the future.

[nallath]

I also forgot to update the number to 2.4. I did that yesterday, so everyone with the 2.3.1 release should get a notification.

[catch22eu]

Usually not the easy way to implement from development perspective, but probably appreciated from user point of view: have applications update natively, ex.:
OSX: App store
Debian (linux): .deb via official repository
etc.

[probonopd]

Debian (linux): .deb via official repository

This would mean that e.g., a Ubuntu 16.04 user would be stuck with an early 2016 version and never get a recent Cura... and the applications in debian stable are practically outdated the minute the distribution is released.

[catch22eu]

This would mean that e.g., a Ubuntu 16.04 user would be stuck with an early 2016 version and never get a recent Cura... and the applications in debian stable are practically outdated the minute the distribution is released.

Package maintainers can update a package with new versions as they please, for whichever release they please. This requires the introduction of maintainers of these packages. Updating these packages can be part of the development cycle of the software. It requires some more effort when releasing new software though, and selection of which packages and distributions to support, but relieves these users from updating hassle, as the OP points out. Just a thought...

[probonopd]

Package maintainers can update a package with new versions as they please, for whichever release they please.

As far as I know, distributions such as Ubuntu and Debian don't update the versions anymore after the release, especially of LTS versions. Which means that users would have to introduce third-party backports or ppa repositories into their systems. Compared to that, I prefer the current solution much more, that is, download the latest AppImage and be done with it.

[awhiemstra]

Compared to that, I prefer the current solution much more, that is, download the latest AppImage and be done with it.

In fact, it is one of the main reasons things like AppImage and Flatpak are gaining popularity: It makes it easy to have a recent version of the software without needing to make changes to the base platform.

[thopiekar]

@awhiemstra : A more recent version doesn't mean that you have always less bugs :wink:

[ianpaschal]

This is actually something which we're not looking for help implementing it; instead it's been discussed and veto'd by others in the company. In light of that, the Won't Do label is more appropriate.

But trust me, I want it too.