![](https://secure.gravatar.com/avatar/da275274bab3cdbc839a9d0e8f2c2299.jpg?s=120&d=mm&r=g)
What's more important, the exit status of the context command is 0 (via echo $?) indicating that there was no problem at all! This might turn out problematic as soon as documents are processed in a batch run ... (like e.g. a regression test suite ;-)
*You* want to write a test suite for ConTeXt?
Well, not exactly ... this might be too ambitious an endeavour for one person alone ;-) I'm trying though to store a bunch of test cases locally which I sporadically collect from the main mailing test whenever a bug report shows up. If only to have something I can test my installation package against ... For the moment I'm mainly interested in whether these test cases compile at all hence my remark about the exit status ... (After all, if that can't be automated any further verification steps will be pretty much useless I guess.)
Perhaps one could even integrate this requirement check into the module loading code of the kernel. For example, one might enforce that each valid module has to declare a field like "minkernelversion" in its header ... just thinking out loud.
The problem with such systems is they lead always to incompatibilities with older ConTeXt installations (think about TeXLive) and we had one at the end of last year when Hans changed the multilingual interface to allow a persian interface.
I agree that my suggestion would sacrifice backwards compatibility. At the same time I'm not sure how much change to the MkIV kernel is desirable given that MkII is considered frozen. I'm really in no position to have an educated opinion on whether there should be as few changes as possible or rather the occasional clear cut. It's just that if you guys think that some clear cuts are due for MkIV anyway then there will probably be never a better time than now to make module loading more bullet-proof. As I was saying, I'm just thinking out loud ;-) Oliver