Recently I have been plagued with clients that have installed modules that didn't work on their DotNetNuke versions because the module had dependencies on a specific DotNetNuke version.  However, the developers never put a hard set requirement on the module installation package allowing the users to have a corrupted site.

This article takes a look at the issues behind this, the common thought processes on compatibility, and provides a built in solution that could resolve this risk all together.

Modules, Compatibility, and Developer Responsibility

Al,

Yes, I can understand...but something like that would require a different setting....(minversion) or something like that as the compatibleversions is designed where it must validate as true for all versions that the module can be installed on.

The only good part is that with the RegEx code, it is VERY simply to update to set it to work for whatever version you need.

Bill,

You bring up a very valid point, I just noticed this now.

However, I found a really easy workaround for it.  Basically you use an option statement, if working with the current version (4.x for example) you use the first part of the option to validate those versions....then you add a second condition to validate all future versions of DNN.  So for example, below is a TRUE script that will validate for 4.6.0 or later.

^([0-9]{1}[4]{1}.[0-9]{1}[6-9]{1}.[0-9]{1}[0-9]{1}|[0-9]{1}[5-9]{1}.[0-9]{1}[0-9]{1}.[0-9]{1}[0-9]{1})$

This will validate true for values like the following....04.06.00, 04.06.01, 05.00.00, 05.01.01, etc, providing the proper validation.  If you want to test it feel free to drop it into my RegEx tester to see how it will be evaluated.

I will update my blog posting here momentarily to include the new script!