SCALE14x fun - openSUSE, KDE

Last weekend was SCALE and I had a lot of fun. Thought a report on the KDE/openSUSE presence would be good!


An impression from the trip - as in, Oslo->Los Angelos.


The event started with talks and I even managed to join the keynote by Corey Doctorow before heading to the booth!

openSUSE

If you didn't know it yet, now you do: both the KDE and GNOME booth are organized by openSUSE, and more precisely Booth Master Drew Adams. His energy makes, I think, openSUSE the most active community booth at FOSDEM with about a dozen volunteers (!!!). He keeps bringing in new people, amazing really. The corner booth worked out great though they wanted to try and move the openSUSE booth to be next to the SUSE one (which was sandwiched between Mageia and the FSF). Thinking about it now - it would have made SUSE pale in comparison...

Such a great presence at an event has a real impact in many ways, from introducing people to openSUSE and giving users a chance to chat about it to also showing people the Geeko matters and what it is up to. Plus, it's a great time for the team, too. So, awesome many points for Drew, really. Next time you see him: give him a hug!


The openSUSE Booth where visitors were thought about the Ways of the Geeko: Tumbling and Leaping!

KDE

I asked for volunteers in a blog some weeks ago and the good news is that people stepped up! Scarlett, who's working on becoming a Debian maintainer, as well as her Debian sponsor Diane, both stepped up to help out. Backbone of the booth this year was Barrington Daltrey who hasn't been representing KDE at SCALE for some years but decided to get back in the game again. A massive thanks to all three volunteers! I'm hoping that next year, Bert and Linda Yerke (who couldn't make it this year) are able to join again, we can have a real KDE party then! Especially as the Yerkes created some great swag last year (the awesome Konqi stickers!) and I have high expectations for what they might bring in 2017.

In any case, with these volunteers, the booth was staffed and lots of people could get their questions answered and had a place to leave their praise and thanks.


GNOME and KDE - brothers in arms!


Scarlett took a pic with me ;-)

Others

Of course, there was also the GNOME booth, well staffed and with demo devices. Walking over the rest of the exhibition hall, I spotted other distro's and projects. Elementary looked nice (their icons seem their biggest asset, seeing how they were promoted) and I talked to people at the Ubuntu booth. Their booth had a big Dell banner and two Dell employees to talk to about the Dell Developer Edition laptops. A great project and the team is doing an amazing job! Soon, the new Dell XPS devices will become available through the program and I'm thinking about getting one.

I must admit, though, that after putting the Dell XPS 13 next to my own Samsung np900x3c, the Samsung still feels sleeker, thinner, lighter, more durable. Sadly, the Samsung was a bit ahead of its time and battery life is a serious weakness. I take battery life over performance and big screens any time (not over ram, though, I want 16GB to stop running out of ram). So I'm hoping for a premium, Core M based (passively cooled) laptop from Dell, WITH Ubuntu on it. One can dream, right?


SCALE is tiring or relaxed, you pick.


Swapnil interviewing Elementary!

Besides the booths, there were also talks and lunches and dinners and conversations with loads of people


HP had only a magician at their booth. Fun, yes. But I prefer the real stuff ;-)

I'll next do an ownCloud-at-SCALE14x blog, but separate as that's where I spend most of my time and I thus have a lot to write about it!

Patching ownCloud: get your fix NOW

you can also get quickly loading kittens!

Sometimes, there's something broken. Or, there's a feature you want in your ownCloud installation now. Not after the next release, NOW!

Well, if the code has been developed but not yet released, you can have it. If you're willing to put in a little work and take a bit of risk!

Let me show how it works.

What we want

Say, you just added 3000 holiday pictures to ownCloud. When you load the folder with the images in the web UI, it is very slow as all thumbnails have to be generated and provided to your browser! What if ownCloud could simply generate all of them during, say, tonight?

Awesome Oparoz has developed code which gives the occ command the ability to run through your ownCloud, either in its entirety or per user account, and generate all thumbnails. But this code hasn't been merged: Oparoz wants to create code tests first before he merges this, to ensure the quality of the code base. Sadly, he hasn't had time to create tests and nobody else has stepped in yet...

(edit: some years later, this has become the super cool Preview Generator app you can just install from here.)

How we get it

How to get this code? Github has this cool trick where you can add .patch behind a pull request URL, like this: https://github.com/owncloud/gallery/pull/387.patch.

Patch your ownCloud with it! This is how:

1. log in to your server
2. navigate to the Gallery app folder
3. grab the patch: wget https://github.com/owncloud/gallery/pull/387.patch
4. test patching: patch -p1 --dry-run < 387.patch
5. If you get only a checking [filename] you're all good!
6. If you have errors check if you are on the right ownCloud release (the patch might be for the latest master and not work on the release you have) and see if you are in the right sub folder.
7. Now run patch -p1 < 387.patch
8. Go and enjoy your feature...
9. If you want to undo the change run: patch -p1 -R < 387.patch

NOTES:

• of course - everything's Nextcloud now - where most the development on former ownCloud code base is happening.
• be careful running random code from github in your Nextcloud, just like experimental apps - this is untested by definition.
• Also, if you go and add all kinds of patches which end up burning down your house and killing your kittens you have only yourself to blame. I gave you a knife, YOU decided to stick it in your eye.
• Last but not least, if it works (or doesn't) report back, this is called 'testing' and very valuable to us!!! It will help get the code merged sooner.
• Idea to blog about it came from the ownCloud meetup evening before publishing - we still do monthly meetups in Berlin and other cities for Nextcloud ;-)

Get Started With ownCloud App Development in Six Steps - the Quick and Dirty Way!

ownCloud Mail, a great newcomer

What's simpler than downloading a zip file, extracting it and running a command in the resulting folder to get an ownCloud server up on localhost?

Yes, it can be that simple, though it might require a few minor tweaks and you have to make sure to have all ownCloud dependencies installed.

Note that this is useful if you want to develop an ownCloud app. If you want to develop on the ownCloud core, a git checkout is the way to go, get started here. Feedback on this process is highly appreciated, especially if it comes with a pull request for our documentation of course ;-)

Step 1 and Two: Dependencies

• Install PHP and the modules mentioned here
  Your distro should make the installation easy. Try these:
  
  • openSUSE: zypper in php5 php5-ctype php5-curl php5-dom php5-fileinfo php5-gd php5-iconv php5-json php5-ldap php5-mbstring php5-openssl php5-pdo php5-pear php5-posix php5-sqlite php5-tokenizer php5-xmlreader php5-xmlwriter php5-zip php5-zlib
  • Debian: apt-get install php5 php5-json php5-gd php5-sqlite curl libcurl3 libcurl3-dev php5-curl php5-common php-xml-parser php5-ldap bzip2
• Make ownCloud session management work under your own user account.
  Either change the path of php session files or chmod 777 the folder they are in, usually something like /var/lib/php (debian/SUSE) or /var/lib/php/session (Red Hat).

The Final Four Steps

• Download the latest ownCloud zip file.
• Extract it in a folder where you want to get going.
• Enter the folder and execute: php -S localhost:5000
• Visit http://localhost:5000 in your browser

ownCloud should present you with its installation steps! Give your username and password and you're up and running with SQLite.

Alternative with OCDev

An alternative is to use OCDev which you can grab here. After installation, you run
ocdev setup core

See the app development tutorial here.

Start with the app

Now you create a subfolder in the owncloud/apps with the name of your app and put in a skeleton. With OCDev:
ocdev startapp MyApp

By hand, you can copy an existing app and hack that up ;-)

It's probably wise to now get going with the app development tutorial here. Be sure to check out the changelog, we try to make sure the latest changes are noted there so even if we didn't manage to fully update the tutorial, you can find out what will and won't work in the changelog. Also, be sure to update the links to get the latest dev doc - this all links to 9.0, once that is out it is probably better to directly target 9.1 and so on.

Your input is very much welcome! If you run through these steps and get stuck somewhere, let me know and I'll update the documentation. Or, of course better still, do a pull request on the documentation right in github. You don't even have to do a full checkout, smaller fixes can easily be done in the web interface on github.

Thanks, good luck, and have fun building ownCloud apps!

How to Upgrade ownCloud: Don't Skip Releases!

If my blog with 5 reasons to upgrade your ownCloud was convincing, you might want to know how. To help people who want to upgrade ownCloud, I always publish a .org blog about upgrading the day after a major ownCloud release. Upgrading any complex piece of software can be hard and while we do what we can to simplify it (with major work coming in that area for 9.0 and onwards) it is never smart to 'just' upgrade without reading documentation and release notes. But there's one tip I want to share in particular: don't try to skip releases!

Upgrade Process

We got excellent documentation on upgrading - read it. I also strongly recommend to have a quick look at the release notes before upgrading to a major release. Find the ownCloud 8.0 release notes here, 8.1 here and 8.2 here.

What you MUST know:

• Do not skip any major releases. We have added code, at some point, to make this impossible - don't try to work around this but first upgrade to intermediate releases! This is also one of the reasons why regularly upgrading is a better idea than waiting to the very last moment and then upgrading multiple releases. Regularly upgrading exposes users to smaller user interface changes in each release and avoids a big 'flag day' where you have an extended downtime due to the upgrade process.
• First upgrade to the very latest bugfix version of your current release. That gives you the benefit of all improvements we made to the upgrade process since the version you run. Count on upgrading from 8.0.5 to 8.1.x going smoother than going from 8.0.1 to 8.1.x!

So if you are, for example, on ownCloud 8.0.2 right now, first upgrade to the latest stable bugfix release (8.0.10). Then upgrade to the latest release in the 8.1 series, 8.1.5 as of this writing. Finally, you are ready to move to ownCloud 8.2.2. If you need packages for these intermediate releases, you can find them on owncloud.org/changelog.

I blogged on .org recently about the improvements to our upgrade process we've been working on.

Enjoy your fresh ownCloud ;-)

I'll be at SCALE and FOSDEM, how about you?

Next week, the Fourteenth Annual Southern California Linux Expo kicks off in Pasadena, LA. A week later it's FOSDEM time, in Brussels, Belgium. Both events have a ownCloud booth and a KDE booth, and both can use some help! More importantly, I have to tell you why you should bother.

  

Helping at a Booth

You might read this (and other blogs asking for help at a booth) thinking

"why the heck would I bother"

or

"why me, I've never done this before"

It seems, perhaps, a crazy tiring and difficult thing to do, standing at a booth and talking to people all day. Coding beats it any time, you'd think. Well, believe me: reality could surprise you!

Let me ask first:

Have you ever visited a geek conference like FOSDEM, SCALE, or something smaller, locally?

If not, let me tell you - it is a blast. Interesting technology but more importantly - interesting people. Often, you can talk to the people who "do the work" and believe me, they have things to say.

"Conferences are like rock concerts: the back stage experience is THE BEST"

But let me tell you a secret. Conferences are like rock concerts: the back stage experience is THE BEST. Seriously, being part of the booth team adds a whole extra dimension to the experience. First, because you get to talk far more intensely with the rest of the team - you'll be there setting up the booth, having breakfast in the morning and beers together at night, plain awesome. But don't discount the visitors. Many have interesting questions and stories to tell and the conversations can be fascinating.

The Good Stuff

Now you might say:

"but it is hard work, right, with hard questions to answer? And all I get is a free entree ticket..."

Yeah, true on the ticket. And you might not be a huge fan of people and talking in the first place, perhaps, I get that, too.

But you're still wrong about it. You see, these conversations aren't like a typical birthday party chit-chat where you have to explain (again) what you do, be nice and social to your aunts you don't like and all that. Nor is it like the pressure of a business meeting, or a networking session. It is nothing like that!

It is hard to explain, but let me try. It is more like trying to help that colleague who recently joined and just doesn't know the product very well. See, people are almost always nice, interested and just as geeky as you. You might not know the but it isn't about that: they don't really talk to "you" but to "KDE" or "ownCloud". Even if you're not naturally a speaker or enthusiastic, the conversations are very easy. As a matter of fact, after having had five, you'll notice four of those went almost exactly the same and you'll develop a kind of elevator pitch, not the fancy ones, but the ones you just naturally assume. Believe me, before you know it, you'll be approaching people who haven't asked a question yet and ask if you can help them.

"Some visitors can be best described with words usually bleeped out on TV."

The difficult people

Of course I won't claim it is all, always easy. Sometimes, visitors can be described with words usually bleeped out on television. I won't lie to you. But even this isn't too hard to handle. First, because you don't write all of the code in your project, or even none in many cases (like mine). You don't have to take it personally. Plus, realize that, in most cases, those being difficult do it because they care: they wish the project was more, better than it is - that happens to be a wish you share with them. Often it just isn't meant half as bad as it might have sounded and a quick conversation shows the common ground. Moreover, you are not alone. You have your team mates to back you up (or complain to after the visitor left) and hey, that's just bonding, right there!

I think that without the few bad conversations, the really good ones wouldn't stand out as much. Yes, there are really nice, energizing conversations. From people who just come by the booth to tell you how much your project (and by extension you) rock to people who tell you, sometimes to the point of really getting emotional, how your community has provided them with something amazing. At those moments, you just soak in the love. Be sure to record or note down any concrete compliments so you can share this later with the community online, in a blog or just a mail to the development mailing list!

If you want to learn more, I've been writing a how-to on organizing a booth and collected some practical tips for conversations with the visitors on this page. More tips welcome!

Now, how can you help?

KDE

The KDE booth at SCALE is actually a bit in trouble. We have some folks who have been helping out the last few years but, perhaps in part due to the early dates, just couldn't make it this year. If you're a KDE user, contributor or just fan, think about helping out! If you use KDE software, especially Plasma of course, and occasionally follow the blogs, you'll have what it takes to help out. Most questions are basic and there are always others around who can help out a bit here or there - including myself, I'll check in a few times for sure. And the openSUSE booth next door, which helps organize the KDE and GNOME presence at SCALE, has plenty of experts in all areas as well. You won't be without backup, not at all!

KDE at FOSDEM already has six volunteers (see the wiki page) and we unfortunately only have one table this year. While help is always welcome, this ain't super urgent. It IS fun, though, so if you're up for it, give it a try!

ownCloud

Matt McGraw and myself will staff the ownCloud booth at SCALE, ready to answer any questions you might have. We're just with two people, so we'd sure welcome a third person! If you're interested, just shoot me an email or comment here. It isn't difficult - I'd even say that if you've been using ownCloud for a few months you can already provide a lot of help at the booth, and Matt and myself are always there.

At FOSDEM, we have a few more volunteers but I also know, from last year, that the booth will be flooded with visitors so if you're up for helping out, even if it's just a few hours, please let me know!

I hope to see you at one or both of these events and that I've motivated you to help run a booth ;-)

Use ownCloud provided Packages, then VM, then Zip, no distro packages.

Last week I wrote a blog about why running an old ownCloud release isn't more stable and you should upgrade. There are many ways to install, run and upgrade ownCloud. What is best depends on your situation but some general rules of thumb can be given.

Use ownCloud Provided Packages If You Can

The best solution from a security and stability point of view are the official ownCloud packages, provided you have the basic know-how needed to run your own Linux server.

Packages give you the advantage of a relatively clean and easy upgrade process, with the ownCloud team taking care of any special steps which have to be taken. The upgrade itself will still have to be kicked off by the system administrator (see our latest update) but you won't risk forgetting to remove old files, correcting file permissions and so on.

We do not recommend using distribution packages, for several reasons:

•  First, there will inevitably be a lag between what distributions ship and what we make available.
•  Second, it happens that distributions don't grab the right code (like relying on a git tag rather than final zip files) or miss changes in dependencies which can break installations.
•  Third, many distributions are reluctant to upgrade to newer ownCloud releases, which means you can get stuck on older versions. While security fixes are often still back ported, being on, say, ownCloud 7.0.4+dfsg-4~deb8u3 means you have missed out on many ownCloud fixes and improvements. And of course, they continue to ship major server releases and ownCloud client versions until long after we've abandoned them.
•  Four. Not offering the latest ownCloud bugfix version also means upgrading can become a tricky problem: we recommend to upgrade to the latest bugfix version in a series before upgrading to the next for a reason. ownCloud 7.0.12 will contain bugfixes related to the upgrade to 8.0.x, fixes for problems you might run in to when you try to upgrade from your distribution's older bugfix release to a new major release. On top of that, our upgrade code looks at the ownCloud version to know how to upgrade - good luck if you run a Frankenstein version. Also, we don't support skipping ownCloud releases on upgrade. So once you're ready to upgrade your distribution with ownCloud 7.0.ancient to a new distro with ownCloud 8.2.shiny, well, it won't work.
• Last but not least. The distribution packagers try to do weird shit, shoehorning ownCloud (and other web apps) into their rules made for C/C++ apps. You'll find packagers trying to move the ownCloud configuration php file out into the /etc folder or split up ownCloud core in separate packages because we maintain some external components as part of our setup. Of course, this breaks in beautifully surprising ways and provides few if any of the benefits they are hunting for. It is also a performance issue. And problems will only get bigger with the upcoming code integrity checker.

I blogged on owncloud.org about the issues with distribution packages (and the distribution model in general) earlier.

"the misguided policy of not updating to even bug fix releases which some distributions have is nothing but harmful for users"

The last of the five points, distributions struggling with projects which don't fit their rules, leads to things like Iceweasel. If you're new to the world of Linux distributions, this is a tale you'll love: on Debian and perhaps soon, Fedora, Firefox is named Iceweasel. Debian does not want to update software because "that would break stuff", instead, they forked Firefox to backport security issues. I'll leave it up to you to decide how secure it is to have packagers 'maintain' software long after the project itself has moved on...

Of course, it also leads to changes coming in big chunks - we've learned that users adapt to changes far better and easier if they come small and regular. That is why mobile apps and many websites introduce changes in an Agile way. ownCloud and linux desktop KDE also increased their release speed for this reason.

I understand the reasons behind the rules and sometimes it has a pay-off which is worth the extra effort. But, as always when things are taken to an extreme, it is now blocking distributions from adapting to 2016 and onwards. The result is that technologies like Docker and the sandboxed apps the GNOME and systemd teams are working on will make much of the distributions irrelevant. A future distro will be a small base on which you run some kind of application image which comes with its dependencies built in. Is that the most secure solution, perfectly disk-space or memory efficient? Perhaps not. But by chasing perfection, distributions failed to attain good-enough.

Anyhow, enough rambling, let's talk about what to do if packages don't work for you.

Use a VM if a Server is Hard

Not everybody is comfortable on the Linux command line and while there is excellent documentation on running and securing a Linux server, it might make perfect sense to go for the Virtual Machine option. Since ownCloud 8.1 we've provided official ownCloud VM images and there are also several third party images available. This way, you get a server installation which has been set up by our experts to be secure out of the box. Upgrading and responding to immediate security threats is still in your hands but we've done what we can to make it easy.

Use Zip Files or Installer if all else fails

On some systems, like cheap hosting or a NAS, your control over the system simply does not extend to the installation of packages or running a Virtual Machine. Then, the zip files (or, for convenience, the installer) are your last resort. While the zip file is easy to use ("just extract and go"), it requires special upgrade attention which might discourage you from staying up to date. And that introduces a security risk! Also, doing the upgrade process from the web UI has limitations and risks on large installations.

Now you've learned why you should upgrade your ownCloud and what installation method to use. Time to get started!

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!

Enterprise

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.