This is an interesting question. Having some kind of API versioning like PTP might be a better approach. So both module and core have version X.Y defines. Minor version are backwards compatible (e.g. add new functionality but don't affect existing), major versions are incompatible. OTOH, doing this globally means that modules which aren't really affected would need to be updated when some other part of the API changes.
I do agree that possible current mechanizm could be improved.
Why I use revision:
- It require no additional work from developer to change core version (and so decrease chance to forget something)
- It make more userfriendly message. If revision is below than expected, module system say what revision you need. In case of API version system is end-user know what API it is in exact revision?
It have cons: - Changes of functionality should be limited manually.
It slightly duplicate other automatic checks. But it purpose is beeing just simple user-friendly check.
BTW: Is it possible to get SVN revision of current source code?
How limits are working now:
- Check FLAT version.
- Check requirement for branch. (main,DE, SDM,...). If fail say "Require different branch"
- Check is revision >= than required to module. If fail say "Require XXX revision"
- Check is platformid is equal to required. If fail say "Require platformYYY"
- If one of imported by module symbol out of range - then it require upper revision but don't know which one. Say "Require different revision".
- If module_load callback in core or in module return "fail", then also say that "CHDK mismatch". This is the way to make any comparision and check that we need.
What limitiation of common major-minor system I see: we have a lot different part of core. If we change the way in which works one of them and because this change major version, then other modules will be rejected also althrough they work ok