Closed matentzn closed 4 months ago
I don’t understand the point of this.
Let’s say a new test is added to the ROBOT’s master branch. What good does it do to ODK users to know that a new test is available in a version of ROBOT that is not the version that is included in the ODK, and that may not even be published yet?
Hmm, it's true that there could be a small lag between master and release, didn't think of that. But I was hoping to make it easier for people who use a custom profile to get notified if ROBOT supports new tests. Already many ontologies I work with use custom profile.txt files, and are 2-6 tests behind what robot has to offer.. maybe you have a better idea of how to make it easy for a user to understand when there are new tests available?
Given the current frequencies of ROBOT releases, the lag is likely to be quite substantial (a few months at least).
What I would suggest is to bundle the ROBOT default profile at build time. That is, we store somewhere in the ODK a copy of the ROBOT profile (let’s say in /tools/robot/default_profile.txt
), and we compare the profile actually used in the ontology to that.
No need to download anything from the Internet, and this will let people know if there are any tests that are supported by the version of ROBOT available in the ODK that their custom profile does not include.
Of course, when we update ROBOT in the ODK (as we do in point releases), we update the profile accordingly, so that /tools/robot/default_profile
always contain the up-to-date list of all the tests that are supported by the version of ROBOT provided with the ODK.
Is this what you mean?
Yes, exactly.
Fixes #552
This PR: