Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Tracking issue for install-upgrade #6797
Original issue: #6667
referenced this issue
May 28, 2019
That's probably a different feature right? Or why would we need to resolve this as part of this one?
I think this should behave like uninstalling the package, and then installing the newer one, so that would mean that yes, this should do that. Having said this, printing a
Yea, in my original proposal I indicated it should probably be separate. I just included it here for completeness in case people felt it was important.
That sounds good to me.
My perspective here is mostly that of an end-user, but having just read through the implementation PR I do have some opinions on these questions:
As you note, the current set (at least what is listed there) seems to me to be a pretty good set of distinguishers between versions. I was personally only thinking about versions as being criteria—this set also covers more information. It might be nice to update all installations that match the given criteria. For example, if I've installed for target
I think so, but I don't see a way to make this fit with the verbiage
Based on the description given, I think it's just about right. For packaging, I personally am of the mind that
In building Docker images with Crates, I think having
I could definitely see a
I think replacement of remaining binaries is fine, with a warning added indicating that binaries were dropped. Though, since doing so would require comparison of the former and latter states anyhow, it might just be better to uninstall dangling binaries and warn the user that you did that. This could also be toggleable behavior. (Proposal:
There is one additional item—I would like the final version of this feature to just reuse