Closed ptMuta closed 1 year ago
There is already self-update hemtt update
. Just no self-checking etc.
I don't think that's very important with project-specific versions as it works now, as each project will add the version they use or a script to download it (which can also call update).
For global installation, maybe even necessary, at least for Windows. On Linux, you'd install it from cargo I imagine anyways, or even distro's package manager.
There is another thing to think about, from design standpoint. Does HEMTT want to be project-specific, meaning specific version for specific project? It highly depends on how many backwards incompatible changes will be introduced through updates. More of a question for @synixebrett definitely.
Oh damn. I totally missed that it already implemented it, with that specific library non the less 😅
So an automatic check would be the only thing to discuss related to this.
The point about project specificity is a really good discussion, but it's more related to #26
In my opinion a nag about a new version being available is a good idea.
You can do a clear warning about major changes etc. within it if we want to emphasize the user about breaking changes (semver, major version changed), but I don't think protecting the user from breaking changes should prevent us from improving the user experience overall. Automatic updates should, of course, be out of the question for a tool like this.
1.1.0 will have a way to check for updates, but no self-updating.
If you feel this still needs attention, please re-open.
For ease of use and maintenance I think HEMTT should implement an update check and possibly a self-update function. This will allow the users to know when a new version is available without closely following the development cycle and would provide an easy yes/no prompt for the update sequence.
I didn't walk through this library yet, but a github based release tracking and downloading would probably be an ideal implementation for this feature if it would be implemented.