Update to 18.1 and 1.27
calr0x opened this issue · 4 comments
I had to run ./deploy.sh twice to update both of these components. The first one updated LED and then I had to run it again to update Lemmy.
Everything went perfect on both updates but perhaps have your script check if there are updates for both and either prompt the user that they'll have to run the command one more time or perhaps automate that. Obviously it wasn't a big deal but it just might confuse a novice.
Great job!
Thank you for the feedback!
This can indeed be confusing, but I think it would be tricky to do something like that. Currently, I use this phrasing for LED updates:
Line 917 in 497e406
I actually split the update checks out intentionally - first it checks for LED updates, then Lemmy updates. I check for LED updates first, since it allows me to preempt situations where Lemmy changes their tagging scheme, moves GitHub organizations, or dramatically changes the docker-compose configuration. This way, the user always gets prompted to update first, and will never run into issues with upstream Lemmy updates (as long as I am proactive about updating it, that is).
I can't have the script re-run itself after an update very easily, because Bash operates on a line-by-line basis. After I perform that git checkout to perform an update, I don't have much leeway to continue running commands without some instability.
If you have suggestions on how I can improve the wording of that update prompt, I am all ears!
Thank you for the feedback!
This can indeed be confusing, but I think it would be tricky to do something like that. Currently, I use this phrasing for LED updates:
Line 917 in 497e406
I actually split the update checks out intentionally - first it checks for LED updates, then Lemmy updates. I check for LED updates first, since it allows me to preempt situations where Lemmy changes their tagging scheme, moves GitHub organizations, or dramatically changes the
docker-composeconfiguration. This way, the user always gets prompted to update first, and will never run into issues with upstream Lemmy updates (as long as I am proactive about updating it, that is).I can't have the script re-run itself after an update very easily, because Bash operates on a line-by-line basis. After I perform that
git checkoutto perform an update, I don't have much leeway to continue running commands without some instability.If you have suggestions on how I can improve the wording of that update prompt, I am all ears!
Absolutely and I have no problems with the way you do it. Do you think it would be beneficial to detect whether there is an update for both projects and let the user know that they will have to rerun it after or did I miss that?
I intentionally don't check for a Lemmy update until I'm certain the user has updated LED, because everything about Lemmy's versioning scheme could change at any time:
- They could change the way they tag. They previously prefixed things with a
v, now they don't, but they could go back to that at any moment (this would break my update calculations). - They could change their GitHub organization. It's unlikely, but not unheard of.
- They could change the Docker Hub repository they use for official images.
Of course, I can update LED to account for those things, but if a user has not updated LED yet when such a change occurs, they could receive incorrect information, such as "an update is not available," permanently, when there actually was one.
In short, I have it this way to encourage users to always keep LED up to date, at the expense of slight inconvenience.
It's worth mentioning, you can also answer "no" to this prompt, and it will carry on with the Lemmy update as usual.
In the next update I will add a message that asks users to re-run their last command after an update, hopefully to avoid confusion.