[owncloud-devel] Bug#815963: Warn users about unsupported upgrade path

Jos Poortvliet jospoortvliet at gmail.com
Wed Mar 2 21:30:39 GMT 2016


On Wednesday, March 2, 2016 1:10:11 AM AMT Marcos Mezo wrote:
> Sorry to chime in this discussion, even more when it comes from an
> uninformed opinion, as I have not had the chance to browse through
> ownclouds sourcecode or debian patches yet, but:
> 
> I am a happy user of owncloud (installed from the tar.gz on the page).
> I'm using it from the very beginning (even before 1.0) and I love it.
> This is not to say it has been troublefree, as specially with updates I
> have had to resync several times in the early days. I even recomended
> against it's use in the early days (even while I was using it). Now it's
> very stable, and I have made a few installations for some colleges.
> 
> I'm also a very happy user of debian, both at home and at work and I
> tend to trust most debian developers, even if I don't use owncloud
> packages this time in my personal server.
> 
> >> One could easily argue that ownCloud is badly architected if it is not 
> >> able to detect which version it is updating from and to which it updates 
> >> to. From that information it could be able to build a list of actions to 
> >> perform. Other systems manage to do that.
> > 
> > Yeah, I don't think anybody would argue with that - it WOULD be nice. Like everything, it is a matter of priority - making it possible for ownCloud to skip updates simply would have meant to skip some feature work or some other refactoring. And nobody stepped up to do it voluntarily.
> > 
> > Note that it is the same with the other requirements of Debian, like being able to split up ownCloud with config files in /etc, being able to use external dependencies instead of shipping them etc.
> > 
> > It takes work to make that possible. We're an open source project: if nobody wants to do that work or pay for it, it won't happen. Turns out that making ownCloud fit the Debian (and Fedora and other distro's) policies wasn't a high priority.
> 
> Maybe this is precisely what the debian maintainer is trying to do. As I
> said I haven't checked the source, nor talked to him, but:
> 
> - owncloud has obviously some routines to upgrade from one major version
> to the next along the recomended upgrade path. I'd like to think that
> they are not completely intertwined through all the code, but must be
> more or less isolated somewhere.
> 
> Maybe debians maintainer intention is to extract these upgrade routines
> from the different major/recomended versions, put them somewhere in the
> upgrade procedure of the debian package for the new version and apply
> them serially. I'd certainly try to do it that way. It would be like
> going through all recomended updates, only behind the scenes.
> 
> Even if ownClouds code would only be moderately well written, and I'm
> confident it's better than that, I don't see it as a major challenge. I
> might for sure be totally wrong. But I certainly I dislike all this
> bashing each other.
> 
> Sorry for the noise, just my 2c.

Sadly, there is a very good reason we wrote a new, stand-alone installer/upgrader for ownCloud 9.0: the code IS intertwined in older versions and that thus means what the Debian developers wanted to do is something most of us wouldn't dare to try ourselves. Now you can say "what do ownCloud developers know of upgrading ownCloud" but... ;-)

If you were right and things weren't so bleak, we would not be unhappy with their attempt to do this - we'd support it. Realize that we're talking about upgrading ownCloud 7, 8,0, 8.1 and 8.2 - relatively old code. If they wanted to make it possible to skip releases starting, say, ownCloud 9.1 I think we'd say "go for it", as we now have a self-contained upgrade routine.

> Marcos
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.owncloud.org/pipermail/devel/attachments/20160302/e8689567/attachment-0001.sig>


More information about the Devel mailing list