Production channel removal

[KarlF12]

@tessus It doesn’t use an internal database. You run the MariaDB Docker image alongside it, and the schema upgrade is done automatically when you bring up a new version of the Nextcloud image. Very easy to work with. Redis is also run in a separate container.

[tessus]

Yep, I would have hoped that it was setup this way. However, running a database system within a container may or may not be the best idea. It always depends. But that’s off-topic. I will keep Docker in mind next time I upgrade the server. Thanks again.

[tflidd]

@tessus

As mentioned earlier with the result that they break their system. But hey, they can pay you to solve their issues. Otherwise they can go back and use a backup. Seriously, don’t you read the upgrade issues on github and this forum?

Compared to previous owncloud updates, the updates are much smoother in Nextcloud. When I compare the problems to back then, it is much less and the user base is probably larger. Your post leaves the impression that it is impossible to upgrade without problems. There are probably environments and configurations where it is more critical, and for these users it is not a nice experience.

I am not sure if this production channel solves the problem. I’d first prefer an updater where you can chose to either update the current branch or upgrade to the next version.

More and earlier testing would help to spot and fix issues earlier. I have a second test setup with a similar configuration, where I test a new version early with all the apps I use. That way, I am sure that there are few problems when I move my productive system. Not everybody can and wants to do that. But on the other hand, you can’t expect Nextcloud to check the upgrade procedure on each webhosting provider and their specific configuration.

@tessus

It might make some users, including you and tessus happier, I suppose

Wrong again. EVERYBODY who likes to be in control of their own environment, will be happier.

Great. There are a few people who claim to know what everybody wants but it seems there are too few that actually do what everybody wants

Well, I am not happy either with all decisions from Nextcloud, I’d like them to focus more on my needs…

[tessus]

@tflidd

I am not sure if this production channel solves the problem. I’d first prefer an updater where you can chose to either update the current branch or upgrade to the next version.

Yes, it did.

At 16.0.5 the production channel showed 17.0.0 as update, but when 16.0.6 came out it showed 16.0.6, so I could have used the updater to update within the major release. With the channel gone, I will have to upgrade to 17 and can’t use the updater to update to 16.0.6.

[nachoparker]

Just came to say that this is yet another sad theater of users feeling entitled and aggressive and demanding towards an open source project that you should be thankful to be able to use for free when most likely (might be wrong) you don’t contribute in any meaningful way.

@tessus just fork it if you don’t like it. These people are running a company and have to pay salaries and make their decisions in good faith. Why do you think they have to listen to you above everything else? If you think you are helping… you are not at all. We need to be thankful and use positive constructive criticism, not unfounded aggressive claims.

@jospoortvliet I admire you for keeping cool and putting up with this everyday. My advice is to ignore the troll. NC is not perfect but you are doing great.

[tessus]

@nachoparker Hmm, I thought they wanted feedback. But as I thought, feedback is apparently only welcome, if it’s praise. Nobody was asking you to defend or not defend anyone. Unless you have an opinion about the channel removal (which is this topic about) you are the troll.

[trendzetter]

@jospoortvliet

@jospoortvliet

Yes, maybe it would nice if it was possible to tell the updater command line tool exactly what version to update too, eg to only update within the same current stable version. It might make some users, including you and tessus happier, I suppose. It would also make it easier to not follow our recommendation and get a less good Nextcloud experience

What I suggest the updater should allow to follow the recommended route. The updater seems to suggest to update to 17.0.1 also for users on 16.0.5. That is not recommended, possibly fatal going on some issues I saw on the forum. Just jacking everyone without a support contract to the latest version, no reason or flexibly apply is not recommended for anyone. It seems to suggest users without a support contract are not too much appreciated, as does the lack of usable documentation concerning logging and troubleshooting.

[jospoortvliet]

@trendzetter

What I suggest the updater should allow to follow the recommended route. The updater seems to suggest to update to 17.0.1 also for users on 16.0.5.

I agree that it would be better if the updater would first provide an update to the latest stable version in a series before it goes to a next major version. That would be nice to add, and perhaps somebody here is willing to do a PR that makes that happen. Maybe even looking at how it was done earlier in the production channel as it seems to have been doing this.

Thanks for the productive comments. also for @nachoparker @tflidd

[alfred]

@JimmyKater

are not only early-adoptors but as well not really ready dealing with problems some new (un)stable version would bring.

Those aren’t early adopters, but something… different.

[kesselb]

@jospoortvliet

I agree that it would be better if the updater would first provide an update to the latest stable version in a series before it goes to a next major version. That would be nice to add, and perhaps somebody here is willing to do a PR that makes that happen.

I guess this feature is already available. What people are asking you to do is:

		'16.0.5' => [
			'100' => [
				'latest' => '16.0.6',
				'internalVersion' => '16.0.6.1',
				'downloadUrl' => 'https://download.nextcloud.com/server/releases/nextcloud-16.0.6.zip',
				'web' => 'https://docs.nextcloud.com/server/16/admin_manual/maintenance/upgrade.html',
				'eol' => false,
				'minPHPVersion' => '7.1',
				'signature' => 'fdy5tfNIlHvO6d/GMIQ9WIYWD9j0KTKz2LZYCPNl2ulQs3OT6oDPk83uaq9I/mHA
eGCB3v0CMBeEYB6n0UZS95AnQSW5teFBroPcWDgdfkromMUSjD4TwJXedU94VfOx
RFamq6Nd65dqwfQ+PMDMW6E3ySpMLPT3NIOpiVOBnLqOO9AINyCn4lOacNDFINqq
BkPE2oK+QzwXjLV09mpffk7BaZwpNWkGiH6uQp/TcSog2RsNyIdQhhrE2XhkInn5
CKR41re0nUXQUyZBKTaQmOHezIeMHn9Z22Utt7npcVCNpqqb8RxIs8x/TJn9d+TZ
w/2xv2Pr0RV364JfdPO7ow==',
			],
		],

Should announce 16.0.6 for 100% of the 16.0.5 users.

nextcloud-releases/updater_server/blob/03037e2413dcd4e389652f5dfd571991574733dd/src/Response.php#L29-L38

Checking the above code I would assume that announcements for x.z.y have a higher priority than x.z or x. Have not tested it but that’s how I read: https://github.com/nextcloud/updater_server/blob/master/config/config.php

People will still see the announcement for 17 but only if they are on 16.0.6. It’s getting a bit more complicated if you want to rollout 16.0.7 to 50% of the 16.0.6 users. They will probably see 17.0.x announcement for a while until you change the 50% to 100%.

[jospoortvliet]

You are right, thinking about it, this is something we could totally do. I will ask the release managers to do this going forward!

This makes it easier for people who really don’t want to update, but we still recommend what we think is the best thing to do and make that the easiest thing to do.

Now if somebody asks me how to disable the update notifications for a major update, I will

[KarlF12]

I just want to add one other thing to this discussion, and that is it isn’t always a matter of whether someone wants to upgrade. We all like the latest and greatest stuff. I think just about anyone would agree.

The issue is that sometimes it really is a mission-critical installation, and some admins will want to, need to, or even be required by policy to delay upgrades until a release is considered more than stable. To give an extreme example, US military often doesn’t put a product into production until it’s in extended support (basically close to EOL). There are pros and cons to that obviously, and people may agree or disagree, but sometimes that’s just how it is.

Now, I know the follow-up argument is going to be “well if it that critical then you will/should have support already.” And that’s fine, but it should be a supported style of deployment for anyone who wants to manage their installation that way without having to jump through a bunch of hoops to do it.

To elaborate on a point stated previously, there should be an option to hold at the latest patch of the current major version for as long as the admin feels the need to do so. I can do that by way of Docker image tags, but not everyone uses Docker, so a more universal method of indefinitely capping the version would be helpful.

[tessus]

@jospoortvliet

I agree that it would be better if the updater would first provide an update to the latest stable version in a series before it goes to a next major version.

Exactly. That’s what I was saying all along. And it happened to be added to the prod channel because I have been giving feedback over the last few years. But you removed that by removing the production channel. Do you understand now why I am so annoyed?

[kesselb]

@KarlF12

but it should be a supported style of deployment for anyone who wants to manage their installation that way without having to jump through a bunch of hoops to do it.

For such a deployment running a custom updater server is the way to go. 100% control for you. Probably also a option for smaller setups. Fork it on git hub, setup the git hooks with your server and announce the updates if you think it’s time.

nextcloud/server/blob/2b2626566c19280ff207cbfa2c0c235ecae2a79b/config/config.sample.php#L642-L647

GitHub - nextcloud-releases/updater_server: :repeat_one: The updater server...

[KarlF12]

@kesselb

For such a deployment running a custom updater server is the way to go.

That’s a completely overkill solution for one instance of Nextcloud and should not be necessary.

@kesselb

Fork it on git hub, setup the git hooks with your server and announce the updates if you think it’s time.

That’s all well and good, but some of us are network engineers and not programmers.

[kesselb]

@KarlF12 you asked for the enterprise way to do it

[gary-kim]

Should we open an issue on the updater repo?
I’d also like the ability to do purely patch updates with the command line updater. I’m busy at the moment but I can make the implementation when I have some time and we can use the issue to discuss how this could be implemented.

[TrinityDan]

@KarlF12

All I saw on my end was one day I’m using the production channel, and the next day it’s been renamed enterprise and made into a paid feature. That’s not a good look.

I agree. It’s not a good look at all. Just more bait and switch from Nextcloud.

From the Nextcloud website:
“Enjoy constant improvements from a thriving and transparent, entirely open-source community development model, free of lockins or paywalls.”

Kind of seems like a joke in light of recent changes.

[KarlF12]

@kesselb Show me someone who runs WSUS for one other Windows server. That isn’t a reasonable solution.

[alfred]

@gary-kim

but I can make the implementation when I have some time and we can use the issue to discuss how this could be implemented.

If you can do it, help is always appreciated I think.