Allow to specify a version to update to

[nickvergessen]

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.

[Benouare]

Hi.

Just to complete :

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Is your feature request related to a problem? Please describe.
I currently have X nextcloud servers, one of them is used for test purpose. I am currently testing new versions on it, and if everything is ok, i am making the upgrade on others nextcloud instances.

I am currently using the
sudo -u www-data php /var/www/nextcloud/updater/updater.phar --no-interaction
That's is working well and that is a great tool.

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.
I test this server for a while, and after that i have checked that everything was good, I think about upgrade the other instances. Because i know that 'normally' 20.1.5 was/is ok.

After some days, weeks or what ever, it was the time to execute the upgrade on my production servers.
Same thing, i was running the updater.phar. But, at this time the 20.1.6 was released, and nextcloud goes direclty from 19.0.1 to 20.1.6 that i didnt test on my test server!

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.
Current version :
sudo -u www-data php /var/www/nextcloud/updater/updater.phar --no-interaction
With this feature:
sudo -u www-data php /var/www/nextcloud/updater/updater.phar --no-interaction --target 20.1.5

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.
I clearly need to fix this issue on 21.0.3 BUT, at first, i would like to control my update process.
If i take the time to test/validate the version X, i want to be able to upgrade to X and not to Y.

Cheers!

[skjnldsv]

#291 would kind of fix that if we can already provide custom URL

[shurik-io]

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.

[damienvancouver]

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!

[damienvancouver]

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?

[nickvergessen]

26.0.4 is coming! but I can't install it with the updater, because it's already pushing 27.0

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

[damienvancouver]

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).

[nickvergessen]

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?

The last maintenance version receives the update to the next major, the rest only to the last maintenance version.
You can already see it in the beta section for the 26 releases. 26.0.4 will receive 27.0.1-rc.1, all other 26 versions receive 26.0.4:
https://github.com/nextcloud-releases/updater_server/blob/master/config/config.php#L684-L715

The pattern / plan has always been like that. If it was not at some point, that might have been a temporary human error.
The only other thing that could happen is a cached response (I think it's cached for 30 minutes or something a like), in which case the updater would still read the 27.0.0 update because it did not read the 26.0.4 update yet from our server and therefore serves a dirty cache for the time being, while you already see 26.0.4 announcements on social media, the forum, etc.

But well, that's basically what this and the other ticket are about, so no need for something new.

[damienvancouver]

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!