@jospoortvliet Any update on this? I think it’d put a lot of people, including me, at ease.
The change of the production channel to an enterprise channel does have some people worried and the ability to basically do the same thing that the production channel allowed would be great.
Also, if this is done, it’d make my planned change to the updater useless so…
Well, it would be nice… Nah, if someone wants it, it’s not a hard patch to write. Would rather at least keep the notification.
Not necessarily. Being able to specify a version on the command line is a great addition and solves other problems. At one point I was thinking about implementing it myself, but as always I got sucked into other projects.
I’d be happy to collaborate on this. Or did you have something else in mind? e.g. specifying the major version and the updater retrieves the most recent minor update? That would have been my next step (cmdline option)…
I think that’s the right place. If you want some flag “dont_send_me_major_updates” thats probably a bit more work to do. The update_server will always return one version. I see two ways:
Pass &dont_send_me_major_updates=1 and only return updates for the same version.
A more generic approach: Return all available updates for this version. This also requires a new parameter &give_me_multi_version_response=1 because old clients don’t know how to parse responses with more than one version.
For 1 and 2 nextcloud/server and nextcloud/updater need some changes to support the new flag properly. At least 3 pull requests to different repositories is probably a tough start
As start I would extend the updater to accept a specific patch file and the signature via arguments. So people have full control which version is installed.
I identified url, signature, version and versionstring as mandatory information from the updater_server response (probably they are more).
If --patchFile and --signatureFile not empty don’t call $this->getUpdaterServerResponse modify $this->getUpdaterServerResponse to return some information from patchFile. For the version check we need version and versionstring.
Probably curl will accept something like ‘file://local/path/to/nc17.zip’ or check is $response[‘url’] a path to a local file and copy it to $fp and skip all the curl rest.
Paste the content of --signatureFile here.
This method is probably a good place to add all this --patchFile and --signatureFile logic. If these two arguements are present do something different but also return a array with url, signature, version and versionString.
@jospoortvliet I’ve read this tread and I must agree that loosing the Production channel is a bad move.
That’s particularly the case for us, small businesses (5 clients running):
too small to afford your Entreprise plan starting at 50 users
still big enough to not be able to support outages due to unstable updates for the supposed Stable branch.
We are now blocked and without options
This problem is for the server and also for clients. Releases are silent and changelog is hidden and not manageable by admin for client.
(At each update you rolling out several nasty notification and confusing elements making update after updates more and more Nextcloud an adware.
(Seriously what the point advertising on the client connected to a dedicated server for a paid hosted server.))
In the last months I’ve lost a lot of time reverting client updates problems.
Yesterday expecting to fix the HTTP/2 pending issue I’ve updated from Production 16.x to supposed tested and Stable 17.0.2 ( 3,5 months old now)
Result => server down for 3h :
Web Update failed ( back to old times) => needed to move to command line occ:… ( Outage => 1 h)
Unable to access the main page => Check Log => Found the Error source [Undefined variable] (https://github.com/nextcloud/server/issues/19030)
somebody validate an app Metadata for this version without testing it properly since September 30th
=> Disable app ( Outage => 2h and system impaired up to this morning)
Still no solution for HTTP/2 error leaving critical files not synchronised
With the production channel lost, I’m now in fear to be in the first, second or three 10% test random batch in Stable channel.
I hope that your are not going to release silently, on top of that, an automagic update.
It’s seems for some reason NC developers want their product to be a geeky tool for non paying customers.
Even if we are happy to support with the [bounty program] (https://www.bountysource.com/teams/nextcloud) and patches and bug reports
Please just stop making our support difficult by creating new difficulties by removing keys features.
Please also find us a solution to keep a production channel both for server AND clients AND if paid is a requirement an affordable solution for small businesses.
In this last case, we will move both our bounties contribution and support hours to a paid plan. Moving from willing contributors to paying clients is not the same relationship it’s less supportive more requiring. Not sure NC will earn more.
What about instances running 16.x and still being set to “production”?
We have 16.0.7 running still set to production and as of now no update is offered to 17, although 18 has been released some days ago.
Of course I probably could and will solve this by changing to stable sometime, but does the policy change mean that 16.x set to production will stay on that level indefinitely, or is the update really still pending?
The average user not following the forum threads, github issues or the website will probably not be aware of the change. This might lead to the paradox situation of (many?) instances falling back to an old version level, although their admins wanted a stable and secure system by choosing production and relying on this channel.
EDIT: At least minor version updates are still delivered to “old” production users on 16.x. We have received an update to 16.0.8 (from 16.0.7).
EDIT2: And finally the update to 17.0.3 was offered, too.
My big objection was the silent push of the production channel into the stable channel without warning.
I agree that there is a need for the production channel.
Makes a lot of sense for those of us that can’t afford the 50 user license. Red Hat has a production version (LTS) as well as a stable. So does Fedora.
With production users pushed into stable, we are now at risk without warning. While the enterprise users that have paid for 50+ users licensing have retained the so-called advantages of a production environment.
At the end of the day, either Nextcloud wants to gain paying subscribers by doing the right thing or not.
To me, the minimum right thing is to at least have warned customers that they need to do a manual upgrade to stay on the production/enterprise channel.
You don’t own my installation. So you can’t push me into a different channel without my choosing to do so.
At the very least there should have been a warning. Given the update, there is no way to revert back to 16.0.8 now.
I am now going to remove the update notification because it no longer serves a purpose.
I feel as violated as I did when ownCloud claimed that the WebRTC tech (open source and GPL) would only work in the enterprise version. It’s the DAY I moved to Nextcloud.
How does the guy at the top feel about this reduction of the non-enterprise users to the stable channel? I’d like to hear his opinion. He left ownCloud for the same kind of shenanigans.
16.0.6 had only one real bug that was back ported in 16.0.7 - the external storage via SMB because a flag was missing.
Production has historically been a lot more stable and doesn’t change as often. That’s the whole point of production. WIth Stable - you constantly have to read the change log. Now that production is gone, I will manually update to the N-1.
Your ruse has not changed the behavior of those that wanted the production channel. You’ve just created friction and a reason for us to NOT purchase a license. It’s not created an impetus for us to get into an enterprise license.
The best way to sell the enterprise license would have been to simply start providing the smaller plans. That would have eased the friction. And would have made us want to buy the license.
Got a notification because you replied to something I wrote earlier. I’m not able to match anything you wrote to something I wrote. Manual update sounds like a good alternative. Probably even automatable by some shell scripts or a configuration management tool.
Just my two cents as an admin of a “Family NC instance” on a rather limited shared hosting server with one heavy (DAVx5, Win Thunderbird 60.9.1, NC Win+Android client), one regular (DAVx5, NC Android client) and 2 minor (DAVx5) users: I do not care much about “new” features as long as my FOSS ecosystem regarding Adresses/Contacts, Calendars and file/gallery sync/sharing is working in a reliable and stable way so to avoid closed ecosystems like Google, Apple, Microsoft, etc.
In the frequent updates of at least one of the FOSS ecosystem components I’m now “expecting” that sometimes per year things break and need hours of troubleshooting and fixing (see Tb 60 to 68 disabling Add-Ons I need).
I have to say NC updater worked much finer then previously in OC but still being on production the updates (especially major version) are not a carefree act - I had some issues.
All this said I must say I do not feel very comfortable with the Production channel removal or in other words I will trust update suggestions less now and feel like “non paying” users have less choice/control. Having a FOSS product steered by company employed experts on the one hand is giving confidence but on the other hand often takes away at least the impression the community can influence main strategies and core features.
I know a lot of personal subjective feelings, but as we have seen with OC they matter.
Yes, I think the writing is on the wall for the disadvantaging of non-enterprise users, going forward.
One thing that might be worth considering for home users, is using Keycloak Gatekeeper to provide an added layer of security, and make it less critical to update quickly, if the update system is to be made inconvenient. This essentially takes over the job of authentication, and puts your application behind a secure proxy. This makes it far less likely that your private Nextcloud instance could be attacked from the open net.
For what it’s worth, my last NC instance only got updated to 16.0.8. I refrained from doing the 17.0.3 because I now know the NC team doesn’t care that I only want production code and it if I want production level code, I have to manage/upgrade it myself. It’s not that big a deal. But still. Kinda sad.