SVI/ProxmoxVE
1
0
Fork 0
mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-03-31 06:34:17 -04:00
Code Issues 2.6k Packages Projects Releases 10 Wiki Activity

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

New Issue
Closed
opened 2025-11-20 05:15:26 -05:00 by saavagebueno · 2 comments
saavagebueno commented 2025-11-20 05:15:26 -05:00
Owner
Copy Link

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.
saavagebueno added the enhancement label 2025-11-20 05:15:26 -05:00
saavagebueno commented 2025-11-20 05:15:27 -05:00
Author
Owner
Copy Link

@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.
saavagebueno commented 2025-11-20 05:15:27 -05:00
Author
Owner
Copy Link

@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.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
🛑 Failure to comply with the guidelines
breaking change
bug
bug
bugfix
deferred
delete script
dependencies
enhancement
external
feature
github
help wanted
Implemented in VED waiting push to Main
in project pipeline
invalid
investigation
json
maintenance
new script
new script
nice to have
not a script issue
not planned
organization
pull-request
Mirrored from GitHub Pull Request
 question
refactor
rename script
security
update script
website
wontdo
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/ProxmoxVE#1718
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?