-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to specify a version to update to #336
Comments
Hi. Just to complete : How to use GitHub
Is your feature request related to a problem? Please describe. I am currently using the What happen : So on my test server I did the upgrade via CLI. Nextcloud goes from (it's an example, the version used may not exists) from 19.0.1 to 20.1.5. After some days, weeks or what ever, it was the time to execute the upgrade on my production servers. And as "always", I get an issue on this version(20.1.6) that i didnt have on the previous version(20.1.5). Describe the solution you'd like I think that upgrade to the last version of nextcloud by default is the good behavior, but i propose to have kind of parameter, to be able to specify the target version that i would like to have. Describe alternatives you've considered Hum... --target could be the url of the package? or something like --next-one to get the version available just after the current one. Additional context As i said, the version that I used in this example are fake. In my case, I had an issue because of my config.php that completely block my instance on 21.0.3 and didnt block in 21.0.2. Cheers! |
#291 would kind of fix that if we can already provide custom URL |
This is now a year old and nothing happend. I want to poke that again, as when using the Helm chart, it supports for example up to 24.0.2 but the updater pushes to 24.0.3 already ending in a mismatch of the versions. |
This is extremely frustrating that we can't simply specify the version to update to. Once again NC25 was pushed to the stable channel while there were lots of bugs left to fix, and once again I now have orphaned instances that are on 24.0.8 and I am unable to give them the 24.0.9 bug fix. This shouldn't be the case when 24 and 25 are both supported releases! I have now updated my testing instances to 25.0.3 and it looks like most of the bugs that were plaguing me are fixed but I really can't tell right away. So now I'm a minor patch behind on all my production instances. I don't want to update from the .tar.bz2 file, I want to use the updater to do it, but I can't! So now those versions are stuck at 24.0.8 when they shouldn't be. That sucks! |
26.0.4 is coming! but I can't install it with the updater, because it's already pushing 27.0. I looked into the updater source and it's unclear from inspection what the format of the upate server's XML response is. It's also unclear how to test by hitting the update server, no matter what combos of the URL + query string I tried, I couldn't get it to send back any results, it expects an XML file and otherwise blows up with a parsing error (???? could this URL not be human-usable too?) . The entire thing is quite opaque and confusing but it seems to me like the best solution would be the one proposed in #319 , that would allow someone like myself to specify I want the latest minor patch release, and not to upgrade to the new major version.. The update server only takes the version and the release channel as inputs, if it could also accept a --no-major switch, then it could return the correct version (ie. 26.0.4 is the latest stable version for someone running 26.0.3 who doesn't want a major upgrade). This seems like the simplest way to go about this IMO, it would totally solve the real world problem of admins unable to install security patches because the updater forces a new major on them that they haven't yet got approved/tested. It would also be really helpful if somewhere, anywhere (updates.nextcloud.com is the obvious place), it was written for humans what the current versions in each release channel were. Currently it's a mystery.. it's word of mouth on the NC forums and release announcement emails, etc. You have to consult the update page and wait patiently to see what it tells you, you aren't given any ability to double check that information yourself, which leads to further mystery and people upgrading to new majors earlier than they maybe should be? |
As soon as 26.0.4 is there you will be required to update ti that and only then be offered 27.0.x again |
Is there some sort of policy document as to how this is done, other than what's in https://github.com/nextcloud-releases/updater_server/blob/master/config/config.php? With NC 25 that is not what I experienced, the updater was pushing 26.0.1 and 26.0.2 on me despite there being additional 25.x patches available and me being on a 25.x version. I will try again on Thursday I guess and see what happens, I suspect it will be pushing 27.0.1 and skipping 26.0.4 , it all depends on what they set in the config.php file. If it pushes 27.0 again I'll try opening an issue over at the updater_server 's repo and see if we can't get that --no-major flag going or something like that, if not just specify a version... that really would be simplest if you could just override it with --version=26.0.4 . It could print a warning if you were using an EOL version and it could also prevent downgrades easy enough). |
The last maintenance version receives the update to the next major, the rest only to the last maintenance version. The pattern / plan has always been like that. If it was not at some point, that might have been a temporary human error. But well, that's basically what this and the other ticket are about, so no need for something new. |
ah OK, then I think it was probably human error back then, I will give it a go Thursday, check the config.php to see hwat's in there, and report back if I'm having grief. Thanks for the info! |
In some setups code of new versions needs to be "signed off" by some testers/commitees.
Therefor when we release to quickly they would e.g. test 20.0.7, we release 20.0.8, they approve 20.0.7, they have to start over again because the updater does not allow to update to 20.0.7 only.
The text was updated successfully, but these errors were encountered: