Production channel removal

[JimmyKater]

hey @jospoortvliet,

thanks for clearing that up a bit… though i like to add one or two suggestions to it:

@jospoortvliet

We initially planned the Stable channel to get new releases right away, and the Production channel to get them over time, as the description explains on nextcloud.com/release-channels

that’s good. but now that the system got changed it’s about time to change the linked page as well.

@jospoortvliet

people were asking where the update was

note: early-adoptors are ALWAYS going to nag devs about newest releases… but please don’t mistake them for being any majority here. though they complain a lot and very loud. most of them - speaking from my experience here on the forum - are not only early-adoptors but as well not really ready dealing with problems some new (un)stable version would bring.

@jospoortvliet

Usually, the .1 or even the .2 release was the first that was put on stable, and only then incrementally. Once I think we only did the .3 release…

i, personally, missed that out, i think. if you’re referring to major versions as in nc x.0.1, x.0.2 or x.0.3 - if yopu’re referring to RC1, RC2 or RC3 that might be the truth.

@jospoortvliet

So in reality, we were treating the Stable channel as Production and Beta as Stable

that’s ok, again. but then again: why would you offer nc x.0.0 versions on stable when you had production channel offering versions >nc.0.2 ? now well it is like it is and you, of course, put thought into it. but maybe it would be nice offering ne major versions >x.0.2 at stable from now on? or come up with a checkbox where the user could enter a value hinself from which version on he wanted to be informed about “stable” versions - setting it’s default to x.0.0…
on the other hand it’s no problem for me to wait until x.0.2 myself.

awww… and have you taken into consideration that some app-devs would rely upon your release-schedule with former production-channel? like @mdw with his great password-app? or @nachoparker and his team with nextcloudpi?

anyways… another thought: if you guys are withdrawing a “stable” x.0.0-release it would help all users here if you’d make a note about it or we would have the more or less same discussion about “where is my release?” with every new major version. i think withdrawing releases is ok to protect users from possible harm they’d do to their instances… but please please please put word out that you did so.

anyways… thanks for your time and understanding.
cheerio
jimmy

[trendzetter]

Note to self: Do not update on notification but wait at least for .0.2 and a few weeks and check the forum for issues before updating.

[KarlF12]

@jospoortvliet Thanks for the clarification. Please don’t forget in the future, there needs to be a front-page PSA when a change like this is coming. 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.

It reminds me of what the Opsview people did years ago, and I ripped them up down and sideways over it and ultimately stopped using or recommending their product. It’s a software based on Nagios with a fairly good web UI that supports configuration. Opsview Community was the FOSS version and was fully featured. One day they “discontinued” that version and replaced it with Opsview Core, which was basically the same thing, but with a few features such as clustering and SNMP traps now requiring a paid license. Then a couple years later they nixed Opsview Core and replaced it with Opsview Atom, again the same software but now imposing a 25 device limit without paying, rendering it largely useless.

I told them that isn’t a game you get to play with community-driven open-source software. Let’s not go there.

[tessus]

@jospoortvliet
I am sorry, but I am not convinced that you really appreciate feedback, since every time any of you Nextcloud devs read or hear something which is not to your liking you dismiss it.

The fact that you remove the production channel is a mockery to the community. Here’s why:

I have complained for years that there wasn’t a way to lock in the release I’m using and that you force people to upgrade when they want to use the updater.
Long story short, my suggestion resulted in the way how the production channel is currently handled. (You can read up on that on the issue tracker.) So as long as there’s a minor update available within the major release that is installed, the updater will present you that minor update.

You do not allow people to choose the major release, nor do you allow to set a check mark to lock the current release. So the production channel was finally a useable workaround (after me urging for a solution for years). And now, you get rid of the only channel that makes any sense.
There’s not even a command line option to manually specify the update you want.

Your channel systen is a mess that you guys created, because you do not listen to people. I want to upgrade to a version I choose, not to something you force on people.
So I can either do what you want or I have to upgrade manually, which makes the updater useless.

So by telling people that the production channel (which was the only channel useful for people who did not want to upgrade on your timetable) you force yet again your idea of when to upgrade onto people. And we all know that even after .2 the releases are NOT stable.

You really must hate all people who do not want to shell out thousands of dollars/euros for an enterprise release and support contract.

[trendzetter]

@tessus they are hoping to be bought out by Microsoft so they are already applying it’s methods.

The version to update to should be configurable, a choice (with a recommendation). If you choose to update later you should still be able to pick that minor update (eg 16.0.6) if you have 16.0.5. It appears as if this isn’t’ available,if I am not mistaken.

[jospoortvliet]

Let me try to reply to a few things here.

@JimmyKater

that’s good. but now that the system got changed it’s about time to change the linked page as well.

Yeap, I’ll update that page to note that the production channel simply doesn’t exist anymore.

@JimmyKater

i, personally, missed that out, i think. if you’re referring to major versions as in nc x.0.1, x.0.2 or x.0.3 - if yopu’re referring to RC1, RC2 or RC3 that might be the truth.

I meant major releases - what we did now was release 17.0.1 to stable, and that in an incremental roll-out. We did the same with 16, 15 and so on. That was actually what we described on the website as our plan for Production - which is why we remove production.

@JimmyKater

that’s ok, again. but then again: why would you offer nc x.0.0 versions on stable when you had production channel offering versions >nc.0.2 ? now well it is like it is and you, of course, put thought into it. but maybe it would be nice offering ne major versions >x.0.2 at stable from now on? or come up with a checkbox where the user could enter a value hinself from which version on he wanted to be informed about “stable” versions - setting it’s default to x.0.0…
on the other hand it’s no problem for me to wait until x.0.2 myself.

That was NEVER the plan. We only delayed Production EVEN MORE because we already delayed stable. But that was (and is) silly. If people want to wait until 0.2 or 0.3 or something else, thinking that somehow that number means it is some special kind of stable - sure, sure, go ahead. But we’re not recommending it, and via Production we seemed to do that, which was a mistake. The numbers don’t mean anything.

What means something is that a release has, say, 10.000 servers using it and no important problems being reported to us. THEN we say, ok, this can go to stable. Because the benefit of the new features is bigger than the risk of issues for most users. Of course, if you as a special user think you have a different balance between risk and benefit of new features, you can make your own schedule by updating manually.

It is entirely possible that some day, we release a 18.0.1, a 18.0.2 and a 18.0.3 and still we have major issues - and we would not put it on Stable. The numbers are meaningless. What matters is the actual level of reliability, and that is something the release team can decide.

@JimmyKater

anyways… another thought: if you guys are withdrawing a “stable” x.0.0-release it would help all users here if you’d make a note about it or we would have the more or less same discussion about “where is my release?” with every new major version. i think withdrawing releases is ok to protect users from possible harm they’d do to their instances… but please please please put word out that you did so.

We do, in every release announcement I tell people they can expect the updater to give them the release after some time, it can take a month or more. And you can switch to the Beta channel to get it right away. Also, we say that same thing in the text that explains the stable release.

@trendzetter

Note to self: Do not update on notification but wait at least for .0.2 and a few weeks and check the forum for issues before updating.

If it makes you feel better, do it. But as I said above - numbers are meaningless. A forum check is indeed smart but also not 100% perfect, as typically the issues found after release are corner cases that hit, for example, “NGINX users using SQLite on Ubuntu 16.04 with a broken imagick php module”. The smarter thing to do would be to actually test our release candidate, and if it works for you, you can upgrade right after the release and get the new improvements and features 2-3 months earlier than by waiting. Plus you help our community and our users by helping the testing process. A win-win I would say, unless you of course don’t want to help out your fellow users.

@KarlF12

Please don’t forget in the future, there needs to be a front-page PSA when a change like this is coming. 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.

Yeah, we could have done better there. Sorry!

@tessus

So I can either do what you want or I have to upgrade manually, which makes the updater useless.

I get it isn’t what you want. But it is actually exactly what WE wanted to provide: a recommendation. And make it easy to follow our recommendation. Doing anything other than what we recommend is extra work. That might not make it perfect for you, but we have ~300.000 system administrators out there and many are not as experienced and don’t have as much time to maintain Nextcloud as you do. Having them choose a ‘stable channel’ like 15 and stick with that means they get a less good experience than they could have. That is bad for them, and bad for Nextcloud. So if they want it, they have to do a bit of extra work.

@tessus

You really must hate all people who do not want to shell out thousands of dollars/euros for an enterprise release and support contract.

That statement is ridiculous in multiple ways. First, we try to do what’s best for the majority of our users, and sometimes that isn’t perfect for some individuals. Second, people can’t pay for what you want - we simply don’t offer a update channel that updates slower or stays on a stable release for customers either. So it has nothing to do with money. We push and heckle our customers to upgrade as much, if not more, as with other users, for the exact same reason: using an older Nextcloud version means you use software with not only less features, but also less users, which means it gets less testing and less scrutiny which makes it end up a worse product overall. We monitor what version our customers use, and reach out to them if it is old. We tell them in advance of releases and any security issues. We provide special builds when there are issues and so on. A customer pays for a better experience and access to our engineers, not for an older version of Nextcloud unless that is explicitly what they want and even then - they don’t have an updater that precisely gives them what they want as every customer wants and needs something else (plus, wants and actual needs can also diverge).

@trendzetter

The version to update to should be configurable, a choice (with a recommendation). If you choose to update later you should still be able to pick that minor update (eg 16.0.6) if you have 16.0.5. It appears as if this isn’t’ available,if I am not mistaken.

You have that - upgrade on your own choice and your own schedule. 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 so we are not motivated to do the work for that. We try to spend our time to make Nextcloud better for most users. Please remember that you are 1 or 2 out of 300.000 users, we have to choose what helps most of them. Not a few. But I would think that a pull request would get reviewed and, if of good quality, probably accepted, so if you really care about this, you can make it happen.

[KarlF12]

@tessus You can do this easily on the Docker version. If you set the image tag to i.e. “16-apache” then it will remain on the latest image of version 16.

I’m doing this now myself because I’ve always considered it a good practice to wait for the first patch after a major release before I upgrade, and this was my rationale for using the production channel. I do this with everything else, Windows, iOS, etc… We all know there has to be some big controversy with every “dot-oh” iOS release… so to me it makes sense to do the same with Nextcloud.

All it takes to upgrade then is to go into your Docker-compose file, change the image to 17-apache, docker-compose pull, docker-compose up -d, and it’s upgraded in seconds.

I find this method to be less risky during upgrades too because there’s basically no risk of any sort of version incompatibility or dependency issue since everything is provided in a pre-tested image.

[tessus]

@jospoortvliet

I get it isn’t what you want. But it is actually exactly what WE wanted to provide: a recommendation. And make it easy to follow our recommendation. Doing anything other than what we recommend is extra work. That might not make it perfect for you, but we have ~300.000 system administrators out there and many are not as experienced and don’t have as much time to maintain Nextcloud as you do. Having them choose a ‘stable channel’ like 15 and stick with that means they get a less good experience than they could have. That is bad for them, and bad for Nextcloud. So if they want it, they have to do a bit of extra work.

The problem is that your recommendations are really bad. Haven’t you read the issue tracker and the forum. There are a countless people who follow your recommendation and end up with a broken system. The idea of an upgrade system that only follows your notion of when and how to upgrade would only work, if the dev process, QA pipeline, and release management was flawless. In case you haven’t noticed, it isn’t.
You also dismissed the part that something was finally implemented after years of complaining. And now you’ve removed that again. Great job. Very considerate,

@jospoortvliet

That statement is ridiculous in multiple ways. First, we try to do what’s best for the majority of our users, and sometimes that isn’t perfect for some individuals.

That is what you think. But it is clearly wrong. You do what you think is best for the users, but you are dead wrong. Otherwise you wouldn’t have left that option for enterprise users. My idea was finally understood by devs and now you made it a paid feature.

@jospoortvliet

We push and heckle our customers to upgrade as much, if not more, as with other users, for the exact same reason: using an older Nextcloud version means you use software with not only less features, but also less users, which means it gets less testing and less scrutiny which makes it end up a worse product overall.

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?

The only thing that people want is to be in control. You take that away, unless they go the manual route, which is more error prone. The only thing you do is make it harder for people - that’s all.

Less features is better than half-baked ones. You still ignore core issues and problems that have been bugging people for years. Example: Do you have a statistic on how many people are using your admin group feature? Except maybe when users don’t intersect. Everybody I know (or any sane admin) finds this ridiculous and dangerous. Anyway, I gave up explaining why. I just don’t use it, like everybody I know. But I’m getting off-topic, but I had to reply to this “more features are better” argument.

@jospoortvliet

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.

@jospoortvliet

It would also make it easier to not follow our recommendation and get a less good Nextcloud experience

I think ending up with a broken system is probably worse.

[tessus]

@KarlF12 thanks, this might work and seems like a good workaround. Unfortunately I currently can’t use Docker on that server for reasons I don’t want to go into right now.
Maybe some day…

@KarlF12

and it’s upgraded in seconds.

Well, you still need to upgrade the db schema. Also, I would have to have a look at that image first. I don’t trust Nextcloud’s design decisions. As long as they don’t use a database in the image which requires to use persistent storage, it should be fine though.
But if I were to go that route, I probably would build my own image.

[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