Consider axo.dev for shipping binaries

[BD103]

As stated in the Design Constraints:

• The editor should be distributed as an executable, either directly from the Bevy website or via Steam.
  • This makes it easier for non-technical users to install.

I highly recommend using the tools offered by https://axo.dev to do so. Not only are they maintained by highly reputable members of the Rust community, but they're open-source, active, and used by countless other big names.

For starters, I recommend:

• cargo-dist: automatically builds and publishes programs (it even supports installers, such as Windows's MSI)
• axoupdater: automatic, configurable updates

[alice-i-cecile]

Awesome; I'm fine with that to build our binaries. I'd still very much like to ship on Steam, both for distribution and dogfooding though.

[rewin123]

Since we now have milestones corresponding to the roadmap, I took the liberty of assigning a milestone to this PR. Feel free to change the assigned milestone, as "I have no power here"

[Atlas16A]

Have we fully decided on weather or not the distributed binaries will be a "launcher" type to handle recompiling the editor when necessary? or will we not worry about that till later iterations?

[alice-i-cecile]

Later iterations. We need to see what our technical limitations are.

[Atlas16A]

I'd support using cargo-dist, however I'm unsure if we should have automatic updates? Reason being most people will want to use the same version of the engine through out their development to avoid breaking changes between versions.

On the other hand for alpha/beta stages autoupdates can make sense, since it'd be more for feature testing, ensuring things work etc.

[n1ght-hunter]

I'd support using cargo-dist, however I'm unsure if we should have automatic updates? Reason being most people will want to use the same version of the engine through out their development to avoid breaking changes between versions.

On the other hand for alpha/beta stages autoupdates can make sense, since it'd be more for feature testing, ensuring things work etc.

i think it would make sense to have in app updates as oppose to auto updates. so a popup with a notification is show that there is a new version on launch. and if you click no you can go to setting and click update

[BD103]

i think it would make sense to have in app updates as oppose to auto updates.

These were my thoughts as well. When I refer to "automatic updates", I mean as opposed to re-downloading the executable from Github.

[naomijub]

Depending on how many breaking changes we make from one version to the other, auto update is a bad idea. It breaks the user flow when stuff stops working and can be a real pain to get back.

I would limit to a process that checks if there is a newer version available and possibly a link to download it

[BD103]

Yes! Just to clarify: When I say automatic updates, what I mean is in-program updates. The program can update itself without the user re-downloading it. I don't think it should automatically do these updates without user confirmation though.

[naomijub]

Yes! Just to clarify: When I say automatic updates, what I mean is in-program updates. The program can update itself without the user re-downloading it. I don't think it should automatically do these updates without user confirmation though.

Yes I understood that, but to you new point. I would be extra careful with just letting the user approve and self replace. It might have a change that breaks something that the user does. If we could preserve both binaries for an extra approval to self replace would be interesting