That's the simplest form of the proposed solution, in essence, by the looks of it - basically there are two features (ROL and ROOL) and a module will only load if it has the right feature i.e. it's designed for the right branch. The currenty method of deciding if modules are compatible just by comparing a version number obviously isn't enough any more, if the branches are incompatible.
I guess this is also a bigger issue for ROOL now since there may well be development versions of the OS popping up here and there. If the granularity of features can be broken down sufficiently, it should give users of those OSes more of a guarantee that they can use module x as it comes, while module y is dependent on a feature which isn't present (or has a new API) in their OS. As Andrew says in his post, 'It's not just about branches'.
RISC OS in education research Heralded as 'an important step in ensuring a good future for RISC OS systems in UK education', Melotech looks to developers and teachers 10 comments, latest by on 20/9/01 7:43PM. Published: 16 Sep 2001