30 December, 2015

Five Reasons To Upgrade Your ownCloud

On our user mailing list users occasionally report problems with quite old ownCloud releases. Often community members like Chris suggest to upgrade to a newer major version and use official repositories rather than those provided by distributions like Debian. That is good advice. I'll share 5 reasons why an older version isn't more stable and talk about the issues with distribution packages in a follow-up blog.

Older Releases and Stability

The oldest ownCloud release supported, according to owncloud.org/security, is ownCloud 7.0.x, with x currently being at 12. That is, this release has had 12 updates fixing stability, performance and security issues. One could thus argue that this release is more stable than newer releases like 8.0.10, 8.1.5 and our latest stable, 8.2.2.

There are five reasons why that is not really true.

openCloudMesh brings ownCloud to research

1. ownCloud Grows

The rule-of-thumb that an older release has had more use and thus issues have been shaken out is not really true with ownCloud.

The ownCloud user- and developer community is growing all the time. ownCloud 8.2 will have more users in its lifetime than 7.0 had, which had far more than, say, 5.0 ever did and so on. At some point after their release, these newer versions will already have had more users and thus more potential discovery of obscure problems than their older, still supported counterparts. If you're interested in quantifying this, we try and give an idea of our estimated user base in our time line of ownCloud history. There'll be an update early next year with our user estimate as of today, but count on at least double the number of last year.

2. Testing Continuously Improves

With the growth of ownCloud's user and developer community also come more tools and processes for testing. For example, during the 8.0, 8.1 and 8.2 development cycle we've increasingly introduced automated testing provided by the CERN-developed Smashbox tool, which is now routinely used to determine if there have been any regressions in complicated syncing and sharing scenario's. Besides Smashbox, other tools have been added to the roster and manual testing has been improved significantly as well. Older releases have simply not had the benefit of this testing and thus there is the chance of corner case issues still lingering.

3. Back Porting is Limited

Due to many users running recent ownCloud versions and the continuous improvements to testing, most bug are initially found and fixed in the latest or second-latest ownCloud release. From there they are back (or forward) ported to the others, that is, integrated in older releases. Due to the large changes in each ownCloud release, integrating fixes far back often makes little sense and generally speaking, we backport to the latest stable ownCloud version and the one before. Of course, security fixes and fixes for very severe or very simple issues are often brought all the way back to the oldest supported release.

4. Clients Take Advantage Of Server Features

The various ownCloud clients for desktop and mobile operating systems are developed alongside, though not in lock-step with the ownCloud server. Various features which improve reliability and performance of syncing require both client- and server side changes. Thus, running a newer ownCloud client with an older server means you miss out on features which could help protect your data or at least save you from getting some conflict files. For example, there's work going on to have checksums on files, a precursor to the much requested ability to sync file changes rather than the entire file. This deals with the rare but not impossible cases where files get mangled while in transit or on storage.

5. New Features Improve Reliability

The checksum feature coming with ownCloud 9.0 is not the only 'pro-active data defense' improvement to ownCloud. We will introduce features like detecting apps which break ownCloud and code integrity checking. Earlier we introduced file locking, experimental in ownCloud 8.1 and enabled by default in 8.2. This protects files from concurrent changes which in rare situations could result in errors or even data loss. Especially for large, enterprise installations, these situations might not be that rare due to large numbers of users simultaneously accessing the same data and thus the benefits of upgrading includes getting rid of an entire class of impossible to reproduce issues.

So What Version Should I Run?

Above, I gave five reasons why near outdated ownCloud releases do not tend to be any more reliable than newer ones. Rather, the opposite is true, as newer versions get more scrutiny and thus have more issues found and fixed and have received new features which benefit the reliability of both server, client and their interaction.

Home Users

For home users, I still recommend to run the stable or plain latest release channel. On the whole, the benefit of new features and performance improvements in an up to date release far outweigh the stability advantage of older versions, especially if ownCloud is ran in a typical (LAMP) setup. We release ownCloud versions only after extensive testing and the vast majority of issues found shortly after a release is related to either scalability for large instances or non-standard environments like enterprise databases, caching solutions and so on. Most testers and developers use ownCloud on a recent Linux/Apache/MySQL/PHP setup and thus you can expect PHP 7 on a bleeding edge Apache to be surprisingly reliable, even when compared to a old Debian release. Note that you should test yourself if you really want to be sure that an upcoming release works smooth for you!


If you value stability above all else (that is, over features and performance improvements in newer versions), it is best to track ownCloud releases with a N-1 strategy: upgrade to one release before the latest about 1-2 months after a new version comes out. That is, it would be about time to upgrade to ownCloud 8.1 by now and when 9.0.2 is made available, now to be expected some time in May, 8.2 is your best bet. If you want to be sure the new ownCloud version runs great on your infrastructure and the upgrade goes smooth with your setup, I strongly suggest to get involved in testing ownCloud. It provides the best and only guarantee it works for you™

Of course, IF you value stability to this degree, you are most likely an enterprise user and you should seriously consider getting in contact with ownCloud, Inc. which can help you decide far better than a blog post what version is perfect for you. Besides advice, support and deployment tools, you get a heads-up on security, stability and performance related issues (and work around solutions) and of course have access to our enterprise features.

If you are still running ownCloud 7.0.x and it is running satisfactory, I can imagine you don't want to change. That is fine for about another 2 months (until 7.0.x is deprecated). However, if you experience any trouble, any advice other than 'upgrade' is probably unwise: I don't think it is worth the trouble of trying to fix issues with 7.0 when you will have to upgrade to 8.0 in a few months anyway.

I know, upgrading can be a pain, it is work and all that. But so are problems in old versions of software you're running and even more so is security. We're working on a new upgrade process for 9.0.

And realize you don't do your users a favor by keeping software 'the same'. "Big Bang" releases steepen the learning curve by making users swallow too many new features, and increase the likelihood of compatibility issues with other systems in the environment. Much of the web and apps (especially on mobile) is moving to faster release cycles for this reason.

In all cases, use ownCloud from the official, ownCloud-provided repositories you can find on owncloud.org/release-channels. I blogged about how to install ownCloud (packages, VM, zip files etc) here.

No comments:

Post a Comment

Say something smart and be polite please!