Add version suffix to owncloud folder inside release tar/zip?

Development
, ,
1

While the documantation clearly states that to update ownCloud you should move away the old sources and copy over the config we keep seeing issues on github where the root cause of whatever problem the reporter describes has been caused by overwriting the old sources with the new ones. Sometimes, that may leave files in place that get picked up by the classloader or some css / js magic.

To try and hopefully prevent issues caused by this (more often) I propose to add the version suffix to the owncloud folder in the release tar/zip. Personally, I have set up apache to serve ownCloud from a symbolic link. Whenever there is an update I unpack the release tarball, mv owncloud owncloud-x.y.z, copy the old config, put old oc in maintenance via occ, update the symbolic link, update the now oc, switch to single user mode, test, allow all users to log back in. So far I have not had the need to restore a database backup (coming from oc4.0), but that may have been luck. In that case I can also easily switch back by changing the symbolic link again.

Anyway, what is your opinion? Should we add a version suffix to the ownCloud folder in the release tarball?

  • Nah, keep the folder name 'owncloud'.
  • Yes, please! It will save me an extra mv on every update. Maybe, it will even prevent mixed codebases and save people countless hours of hair pulling, trying to reproduce a weird issue.

0voters

Votes are public.

Show results

Or is there another option?

2

I'm also working with a symbolic link. So for me it would be easier if the version number was included.

3

A suffix would be nice. However if we do add it, we need to make sure to properly communicate this and also adjust the updater code. There are admins out there who might have automated tarball updates and whose scripts might need adjusting.

If we do do it, I suggest only for new releases and leave the past ones as before.

4

This change will require changes in our upgrade machine (cc @jvillafanez) .

5

@SergioBertolinSG The vote is about if it makes sense, not if it will require changes in existing deployment scripts :wink:

6

Sure, we can always modify them.

7

Could help some users on their own server. However, not everybody uses a subfolder for owncloud, so you would need to set a DocumentRoot which is symlinked. And it needs to work on nginx and apache, and SELinux, ...

And our friends on shared hosting don't have this option and they often run in such problems.

8

Deploying OC as a subdomain (I do that) will require you to configure the document root on your own anyway. Adding a best practice to the owncloud documentation should be sufficient. At least it forces you to think about what you are doing instead of giving you a har time trying to find out what went wrong.
If you want to change your document root instead of a link that is a perfectly legitimate way to handle an OC upgrade. If you use SELinux you already need to touch the config because OC might want to talk SMB or open other connections uncommon for a web application.

Ì don't think any of the above outweighs a decreased chance for code mixes, but ..

shared hosting is an interesting point. Maybe we should add a RELEASE-NOTES-9.2.0.md file with the release notes. When a user just copies over the new version he should have more than one RELEASE-NOTES-x.y.z.md which we can then detect and tell him to follow the official upgrade procedure?

9

Maybe it's easy to create another tarball with these changes and keep both. Although ownCloud can promote the new "tarball with suffix" package, the old tarball could be accessible in other place.