[owncloud-devel] Bug#815963: Warn users about unsupported upgrade path
thomas.mueller at tmit.eu
Mon Feb 29 07:25:12 GMT 2016
Am 28. Februar 2016 12:20:30 MEZ, schrieb tflidd <tflidd at aspekte.net>:
>I really appreciate the efforts you put in the improvement of the
>upgrade process and the new integrity check will hopefully reduce
>problems with code of different versions. Just bypassing checks, which
>were put in place for a reason, is not a very good idea.
>Other web applications went the way to provide long term releases
>(https://en.wikipedia.org/wiki/Long-term_support), perhaps an idea for
>owncloud? I think, there are a lot of people who like owncloud but who
>are not so enthusiast that they need every new feature. They were happy
>with owncloud 7.0, and now as it reaches EOL they need to upgrade.
>Unfortunately, it's not one, it's a series of upgrades.
A new major version of ownCloud is not only about new features. Fixing some bugs - especially in the area of performance - do require architectural changes which can only go into major versions.
Finally after 18 month we even don't put effort into security updates.
With respect to the maintenance effort I don't see us in the position to provide a LTS. Sorry.
>This probably requires a different planning and all update-routines
>would have to be adopted.
>Am 28.02.2016 um 11:43 schrieb Lukas Reschke:
>> See also https://github.com/owncloud/core/issues/22313 and
>> We're spending significant time in core on already fixed bugs. I
>> consider this really helpful for us nor our users. This is taking
>> data at risk by intention.
>> - Lukas
>> On Sun, 28 Feb 2016 at 11:15, Lukas Reschke <lukas at statuscode.ch
>> <mailto:lukas at statuscode.ch>> wrote:
>> I stand with my comments. If some downstream people believe they
>> know it better than upstream they are illusional and taking user
>> data at risk. If this doesn't work with the way they distribute
>> packages they should not distribute it OR add extensive testing
>> sets to core to prove that updates will work. And of course users
>> have to follow our update processes. That's why we have code in
>> place that enforces it. If they remove that then they simply are
>> not using ownCloud but a fork which should be marked as such. Our
>> code integrity check will detect such situations. And yes, this
>> a longterm goal that we're aiming at and there are tickets for
>> What they do is taking user data at risk AND outsourcing support
>> to us in case it breaks. An unacceptable move from my PoV.
>> of randomly deciding that this works downstream should have filed
>> an issue and worked with us to the goal to support this in
>> Note that the version that Debian has in stable also is missing
>> quite a few bug fixes leading to data loss. My blog post recently
>> highlighted one. Seriously. This whole "we randomly backport
>> patches that we consider critical" thing is just not suited for
>> fast evolving web apps like ownCloud.
>> - Lukas
>> On Sun, 28 Feb 2016 at 11:00, Klaas Freitag <freitag at owncloud.com
>> <mailto:freitag at owncloud.com>> wrote:
>> On 27.02.2016 15:49, Lukas Reschke wrote:
>> > This is super dangerous stuff from Debian and I*HIGHLY*
>> would advise
>> > anybody from NOT using distribution packages for ownCloud.
>> > Highly irresponsible from them to risk user data like that.
>> Honestly, the
>> > maintainer should know better.
>> Sorry, but this is over the top. Of course debians way of
>> patching this
>> is wrong, but have you ever thought about why they do it?
>> It is completely naive to think that users (using distro
>> packages or
>> not) will always follow the upgrade path ownClouds core devs
>> think is
>> good. ownCloud isn't the center of the world for everybody.
>> 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. If that is too hard
>> with the
>> underlying technology we are using that is a different thing,
>> but in
>> means a reason for this bashing comments. That is not helping
>> We should spend our energy to improve things rather than
>> pointing to
>> each other. In FOSS we're all in the same boat.
>> Devel mailing list
>> Devel at owncloud.org <mailto:Devel at owncloud.org>
>> Devel mailing list
>> Devel at owncloud.org
>Devel mailing list
>Devel at owncloud.org
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
More information about the Devel