[Owncloud] Improvement for the required version test blocking apps

[Christian Reiner]

Hello Michael, Thomas and all, 

> > On Friday, August 17, 2012 10:33:39 PM Christian Reiner wrote:
> > [required version test blocking apps]
> > [suggestion of tag 'compatible' in info.xml]

> On Friday 17 August 2012 16:56:35 you wrote:
> Instead of ownCloud versions, I believe we need to start setting versions
> for the public API and use those for determining what apps work. In any
> case this is something that we should work on before the hard feature
> freeze.
> Since no version for the public API has been set before, should we just
> start at v1?

from a technical point of view this absolutely makes sense on first sight. 
However as Thomas mentioned it also rises the overall complexity without 
really offering a clear benefit beside logical correctness. 
I also think that only to base the compatibility question of the public API is 
jumping too short. There are a number of reasons: 
- most apps actually use more than just the public API currently
- there are dependencies beside API version compatibility (markup structure, 
redirection behaviour, style rules structure)
So either the mechanism would have to consider more aspects in the info.xml to 
have a clean solution (far too complex, so unrealistic) or there are gaps in 
the solution (then why do it this way?)

Since there is no clean solution from a technical point of view things should 
be kept as simple as possible. The only thing that really needs to be changed 
is the current blocking effect of inevitably having all apps broken for longer 
periods around the release dates of new major versions. 

In addition, simply changing the logic at that point seems ok to me currently. 
The current logic is primitive and leads to the effect that right now all apps 
specify exactly one single major version number. A /current/ major version 
number, which ever they target to. It should be save to turn around the logic 
as Thomas wisely suggested without actually breaking an app: 

* tag 'requires': the app relies on features only present from this major 
version, so installing it on older OC installations makes no sense and will 
almosst vertainly break things. New: no restrictions for future versions. 
* tag 'compatible': the app is guaranteed to be compatible with the specified 
major version. The absence of this specification is interpreted as 'not 
compatible'. 
This specification could also allow more detailed settings: for example 
<compatible>4.5</compatible> would make the app usable in the announced 
intermediate version without that is has to be declared compatible to the 
4.0.x series as <compatible>4</compatible> would do. Questionable though if 
this enhancements offers enough benefits to justify its additional complexity. 
* implicit compatibility: an app is always considered compatible to the 
version specified in 'requires'. 
Both tags can be combined this way and the mechanism is backwards compatible. 

It would be a cleaner solution to combine both tags inside a container 
'compatibility' for an enhanced readability, this would also enable easy 
future extension in case it turns out to be neccessary. 
However this means breaking the current syntax. 

-- 
Christian Reiner (arkascha)
[ foss at christian-reiner.info ]