On Friday 17 August 2012 22:33 Christian Reiner wrote: > Hello all, > I would like to suggest an improvement: > > Aparently a few days ago the test blocking apps according to the OC version > they specify as requirement got sharpened again in OC-git a few days ago. > > Obviously this means that all 4rd party apps are broken now again until > updated in this aspect. However we all know this is a problem, since the app > developers have to choose between two bad options: > - break the app for current stable and all installations for weeks or > - leave the app unmaintained until OC5 is declared stable and rolled out > I think we all agree this is a really bad situation. > > Now I don't want to rant about anything, I do see the point why the test was > introduced. However in its current version this test is questionable. It > throws up more problems than it solves in my eyes. It celarly frustrates > app developers and users. > > I want to suggest a better solution for this test: > the format of the info.xml file should be extended in future. The 'requires' > tag should be kept, it servers as a good protection against breaking > outdated installations. I suggest to introduce an additional but optional > tag 'compatible' that accepts multiple entries, one for each version the > app actually is compatible with. This way the app can be used in newer > versions, but only if that has been explicitly specified as possible. So > outdated apps won't break newer installations. > > I hesitate to suggest to make that new tag too complex. Testing against sub > versions sounds attempting and certainly is possible from a technical point > of view. Nevertheless I woud prefer to keep things simple, so limited to > major versions. The tag could be declared optional, so that backwards > compatibility is maintained. > > Any comments or suggestions? > Did I miss anything ? Is this more complex than it appears?
I'm glad you brought it up. First the logic has to be reversed. Now "requires" actually means that apps that require less than the current ownCloud version cannot be installed, so of course it should be the other way around. If say you are running ownCloud 4 and your app requires ownCloud 5 it should either not be listed or there should be a warning. I like your suggestion with a "compatible" tag - it could be several entries or a comma separated list - as long as it's there. And I think the admin should still be given the option to try to install it anyways. But changing that also calls for a refactoring of the installation/enabling app methods. Now an app that throws an exception brings down ownCloud all- together. I'm not sure we should start another versioning scheme besides the general release scheme as that could bring too much confusion. And I don' think we should make any changes to the installation code before releasing OC 5 as currently it almost always works, but we should definitely discuss this and come to a consensus on what path we should follow for the next major release. -- Med venlig hilsen / Best Regards Thomas Tanghus _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
