And it failed spectacularly.
We only needed a simple form, but we wanted to be fancy, so we used “nextcloud forms”.
The docker image automatically updated the install to nextcloud 30, but the forms app requires nextcloud 29 or lower. No warning whatsoever. It’s an official app, couldn’t they wait that it was ready for NC 30 before launching it? The newsletter boasts “NC hub 9 is the best thing after sliced bread” yet i don’t see any difference both in visual or performance compared to NC hub 2
Conclusion: we made our business to rely on nextcloud forms as a signup form, but the only reason we were using it was disabled who knows how many weeks ago.
They’re releasing a new version every two month or so and dropping them rapidly from support, pinning it with a tag means that in 12 months the install would be exploitable.
Now, I did directly to production because this is low priority stuff, but it would have happened even with a testing stage. I would have never noticed that the forms apps was disabled, the system disabled it without any notification.
You would expect that an official app supports the latest release, no?
This wasn’t an app released by a nobody in their free time, this is a main feature heavily advertised in their blog. Look by yourself:
https://nextcloud.com/blog/nextcloud-forms-to-keep-your-surveys-private/
It’s not unreasonable to get pissed when 6 months after that blog post it doesn’t support the latest release anymore.
The lifecycle can be found with a single online search. Here https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule
Releases are maintained for roughly a year.
Set yourself a notification if you forget it otherwise.
Exactly, they have a release schedule, why their own plugin, that they’re heavily promoting as a feature, isn’t following that? If for some reason the forms app isn’t ready for that date, why not postponing the launch instead of having it broken for who know how many months?
It’s not a plugin made by someone else in their free time. They knew that by updating to NC 30 that feature that was marketed just 6 months ago would be disabled, so at least have the decency to write it in the release notes. I subscribe to the newsletter and the RSS for what, just enjoy the marketing buzzwords?
It’s like if Microsoft releases an operating system with a buggy and broken taskbar because of a rushed self imposed deadline and fixes it one year later.
Okay, let’s be angry at the company and frown a lot at what happened. Gurr, bad company, evil.
And now think of what you’d rather have - a working system, or a reason to be angry? If you have something that integrated with something else, lock it down at a specific version so you control the upgrade and know those versions work 100% of the time together. “Latest” is just asking for trouble - be it in a docker image, in dependencies or elsewhere. It’s absolutely not a “best practice” if it isn’t even a code smell or an outright bug. You could’ve had a slightly outdated version, which won’t be “exploitable” - you wouldn’t have enough time to exploit anything in that time, especially with smaller companies and obscure exploits.
Instead of putting out the fire, you could’ve been now looking into the upgrade, seeing on UAT or Test or whatever that forms aren’t supported, chilling till they are supported or complaining that they aren’t.
Upgrades breaking shit is like programming / devops 101, and a huge reason for technical debt in very old projects. Leaving all that to chance is just irressponsible.
the upgrade command is sent manually, it’s not automated and it’s not unattended. It would have made ZERO difference if i tagged 29 and then in test tagged 30. The upgrade would have not failed, it would have given ZERO warnings, I would have seen that everything worked as expected (because who tests the useless survey that is filled once a semester?) and I would have pushed the update to production.
Who tests the useless survey? Everyone with regression tests. Like dude, everything you talk about has been written “in blood” from years of hosting production systems. If the useless survey is needed, then write a test for it, or a testcase to manually try it. Don’t just upgrade, see that the app is up and push to prod, that’s not testing, that’s asking for trouble.
I’m not arguing that my procedure is right (it is not), I’m arguing that nextcloud rushed the release in an incredibly unprofessional way.
When it’s the last time that Canonical, in the hurry to release Ubuntu xx.yy broke snapd without?
When it’s the last time that Apple, in the hurry to release iOS xx, made it totally incompatible with iMovie and had no timeline on when it would be fixed?
When it’s the last time that Microsoft pushed a Windows update that disabled Microsoft office and left it unfixed for months?
Nextcloud decided to take care of the forms app. They decided to promote it as a selling point. They decided when to release the update. They decided to still push the update even if their own form app didn’t get any new release in 4 months and isn’t compatible.
They aren’t contractually obligated to release a new, indistinguishable version (except some new bits that make it incompatible) every quarter.
Not ready? Delay one week. Still not ready? Delay an additional week. It came out that it needs a complete rewrite and it will take months? Write a note in the blog saying that feature is no more a selling point but now it is deprecated/unmaintained/unsupported and it will be automatically disabled without confirmation.
As someone said, a good app is only late until it ships, a bad app is bad until it’s patched. Why being perpetually bad with updates that nobody is asking?