Not that it will have any practical meaning, but I fail to see the reason why? Who is it good for?
The non-enterprise users? I think not.
The enterprise customers? So they can see that theyâre paying for something? They get plenty for what they pay already.
For Nextcloud? Do they really wanna get a bad rep now that theyâve have had such a great process going from a flawed business concept to a healthy one?
It forces all open-source users using the channels to use the current stable channel and test the newest version for enterprise customers ?
In reality, for most users it probably isnât that important. In enterprise environments, the setup is generally more complex, you have a storage backends, external authentication mechanisms âŠ, there is other software and you are a bit less flexible with software versions.
But Iâm with @tanghus, I donât see the point of removing this channel.
you have a storage backends, external authentication mechanisms
Iâm using nextcloud - I am the only user - I use multiple storage backends and authentication mechanisms, incl. Imap authentication. My primary storage backend is S3.
Iâm not going to even touch the enterprise comment but if youâre not making enough money off enterprise users to provide Q&A testing without forcing everyone to be your bug testers in the stable channel then Nextcloud needs to come up with a new business model.
Hmm. I have guess but Iâm not 100% sure. Take a look at the updater_server (https://github.com/nextcloud/updater_server). Iâve checked plenty commits and most of the time they update stable and production at the same time. Actually I donât see a huge difference. Usually they push a new major release a bit earlier to stable.
But thats only the update announcement. If you donât want to update to a new major release just ignore the notification? I have done this for 17 myself and still received 16.0.6 even 17.0.1 was already announce to my instance.
I really wonder about the point here. A lot of posts here are users asking for the Nextcloud 17 update. I would assume that home users are the early adopters. If they would ship the update to their enterprise customers first the other half of the board would complain
For the record, my home setup, which I have taken very seriously and even run on actual server hardware, was using the production channel prior to this update paywalling it.
The argument that home users donât benefit is invalid. I used it as a marker for when the next release was thoroughly tested.
Iâve compensated by using the 17-Apache tag on Docker so I can delay when it moves to NC18.
So the reason behind the Production channel/Stable channel thing is rooted in some history, so let me try to explain:
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
But when we build our updater server, one or another clever person (I think it was lukas or morris) came up with the idea of incremental roll-out, that is, we only roll out Nc to a percentage of the users via the updater to catch problems before they hit everyone.
On top of that, our team quickly developed a habit of waiting a week or two before the Stable channel got the update, and instead using the Beta channel to get the newest version to users. You might have noticed how much our team cares about delivering stable software - I often pushed for putting things on stable quickly, as people were asking where the update was, but then I got push-back - âbut what if it breaks a user systemâ and âI donât want to call it stable until we know it isâ and âyou know, we can never test every scenario so letâs wait a few more weeksâ. Well, makes sense, right?
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âŠ
So in reality, we were treating the Stable channel as Production and Beta as Stable
Worse, we started to forget updating Production, so it was outdated and that introduced a security risk for users on there.
at this point, we had a Stable channel being treated as Production and a Production channel that was actually worse than Stable.
So we wanted to retire âProductionâ completely and just remove it.
But then, recently, we started a special build for our customers (see https://nextcloud.com/faq/ ) and that needed a channel to roll out to them. Re-purposing the now-obsolete production channel seemed to make most sense.
And so, thatâs what we did.
Iâm sorry for the mess and confusion here, we had a nice plan in the beginning but we didnât really follow it so at some point we had to sync with reality. Calling a channel âProductionâ when it is actually worse than âStableâ seemed harmful.
Now yeah, we could try to hide the production channel that delivers our customer build but given that I still get people who say âwhat, there is a company behind Nextcloud that offers customer services? Oh, we decided on another product because we had no ideaâ* I think itâs fine to tell people that if theyâre at a bigger organization there is support available.
And I saw that @kesselb pretty much caught up on this in his comment, by the way
Feedback and ideas are, of course, always welcome.
Iâm not kidding. I know we try to say it everywhere we reasonably can, even annoying some users, yet others still donât pick up on it
thanks for clearing that up a bit⊠though i like to add one or two suggestions to it:
thatâs good. but now that the system got changed itâs about time to change the linked page as well.
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.
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.
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
@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.
@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.
@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.
Yeap, Iâll update that page to note that the production channel simply doesnât exist anymore.
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.
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.
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.
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.
Yeah, we could have done better there. Sorry!
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.
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).
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.
@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.
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,
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.
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.
Wrong again. EVERYBODY who likes to be in control of their own environment, will be happier.
I think ending up with a broken system is probably worse.
@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âŠ
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.
@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.
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.
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.
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âŠ
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.