Easy way to install, or downgrade to, a prior software version #1471

Closed
opened 2026-02-05 00:58:26 +03:00 by OVERLORD · 2 comments
Owner

Originally created by @gh2023-aesun on GitHub (Aug 15, 2025).

🌟 Briefly describe the feature

Create an easy way for script users to install a different version of the base software, the script default currently is latest.

📝 Detailed description

The fancy version would be to modify the Update script to include a downgrade option, so it includes upgrade and downgrade capability.  The user will probably not know a downgrade is needed until after they have run the install or update script, so this would be cleaner than destroying the LXC container and starting renew.

The basic version would be to publish a guide on how to modify the install (or update) script to achieve the same result.

Or maybe implement the basic version as an interim solution, while the fancy version is being developed.

Some background

I had an issue with Palmr (see here) and downgrading to the prior version resolved the issue.

However, when I searched the community for how to perform a downgrade or install a previous version, the advice was to clone the script and make the necessary changes, not very prescriptive.

I attempted the downgraded install by cloning the installation script, changed the two instances of latest to v3.1.7-beta and ran it. Once the script completed I had an instance of Palmr that performed as expected, with no application issues.

However, ✔️ Deployed: Palmr (3.1.8-beta) was printed to the script log and the Palmr GUI also displayed

Image, when I was expecting v3.1.7-beta.

So I know this is not the correct way to do this, but it did resolved my issue.

Thank you all for a great service.

💡 Why is this useful?

There is no guide available currently to correctly modify the install or update script to achieve this (see Some Background above).

Also, modifying the Update script would allow less bash-saavy users this capability.

Originally created by @gh2023-aesun on GitHub (Aug 15, 2025). ### 🌟 Briefly describe the feature Create an easy way for script users to install a different version of the base software, the script default currently is latest. ### 📝 Detailed description The fancy version would be to modify the Update script to include a downgrade option, so it includes upgrade and downgrade capability.  The user will probably not know a downgrade is needed until after they have run the install or update script, so this would be cleaner than destroying the LXC container and starting renew. The basic version would be to publish a guide on how to modify the install (or update) script to achieve the same result. Or maybe implement the basic version as an interim solution, while the fancy version is being developed. ### Some background I had an issue with Palmr (see [here](https://github.com/community-scripts/ProxmoxVE/discussions/6828)) and downgrading to the prior version resolved the issue. However, when I searched the community for how to perform a downgrade or install a previous version, the advice was to clone the script and make the necessary changes, not very prescriptive. I attempted the downgraded install by cloning the installation script, changed the two instances of _latest_ to _v3.1.7-beta_ and ran it. Once the script completed I had an instance of Palmr that performed as expected, with no application issues. However, ✔️ Deployed: Palmr (3.1.8-beta) was printed to the script log and the Palmr GUI also displayed <img width="213" height="62" alt="Image" src="https://github.com/user-attachments/assets/750e0a37-ba7b-49c1-aa1e-cc39c6fca4b6" />, when I was expecting _v3.1.7-beta_. So I know this is not the correct way to do this, but it did resolved my issue. Thank you all for a great service. ### 💡 Why is this useful? There is no guide available currently to correctly modify the install or update script to achieve this (see **Some Background** above). Also, modifying the Update script would allow less bash-saavy users this capability.
OVERLORD added the enhancement label 2026-02-05 00:58:26 +03:00
Author
Owner

@tremor021 commented on GitHub (Aug 15, 2025):

This is already possible with scripts that have undergone refactoring to use helper functions in our tools.func script.
For xample, if a script deploys a release fom github like this:

fetch_and_deploy_gh_release "cloudreve" "cloudreve/cloudreve" "prebuild" "latest" "/opt/cloudreve" "*linux_amd64.tar.gz"

You can change "latest" parameter to whatever version tag the application has on their github. latest is default behavior of the function, so if you wanna download some other version instead of latest, you would do something like this in the script:

fetch_and_deploy_gh_release "cloudreve" "cloudreve/cloudreve" "prebuild" "4.5.0" "/opt/cloudreve" "*linux_amd64.tar.gz"

This will result something like this in the shell:

root@debian-test:~# fetch_and_deploy_gh_release "cloudreve" "cloudreve/cloudreve" "prebuild" "4.5.0" "/opt/cloudreve" "*linux_amd64.tar.gz"
  Fetching GitHub release: cloudreve (4.5.0)
  Deployed: cloudreve (4.5.0)
root@debian-test:~# 

Even though the latest is 4.5.1, this way you can still go back and install a prior released version.

@tremor021 commented on GitHub (Aug 15, 2025): This is already possible with scripts that have undergone refactoring to use helper functions in our `tools.func` script. For xample, if a script deploys a release fom github like this: `fetch_and_deploy_gh_release "cloudreve" "cloudreve/cloudreve" "prebuild" "latest" "/opt/cloudreve" "*linux_amd64.tar.gz"` You can change "latest" parameter to whatever version tag the application has on their github. `latest` is default behavior of the function, so if you wanna download some other version instead of latest, you would do something like this in the script: `fetch_and_deploy_gh_release "cloudreve" "cloudreve/cloudreve" "prebuild" "4.5.0" "/opt/cloudreve" "*linux_amd64.tar.gz"` This will result something like this in the shell: ```bash root@debian-test:~# fetch_and_deploy_gh_release "cloudreve" "cloudreve/cloudreve" "prebuild" "4.5.0" "/opt/cloudreve" "*linux_amd64.tar.gz" Fetching GitHub release: cloudreve (4.5.0) Deployed: cloudreve (4.5.0) root@debian-test:~# ``` Even though the latest is 4.5.1, this way you can still go back and install a prior released version.
Author
Owner

@michelroegl-brunner commented on GitHub (Aug 15, 2025):

You can always Fork the repo and pin Versions if you wish to do so, but we will not implement a way to select versions. This would bloat the scripts to much, and would lead to more issues when people dont use the latest version, much more as the issues here and there with a faulty update.

@michelroegl-brunner commented on GitHub (Aug 15, 2025): You can always Fork the repo and pin Versions if you wish to do so, but we will not implement a way to select versions. This would bloat the scripts to much, and would lead to more issues when people dont use the latest version, much more as the issues here and there with a faulty update.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ProxmoxVE#1471