[HTC EVO 3D] joeykrim:
i don't think there is a definite guaranteed method .. although maybe somebody will prove me wrong as i might be thinking through it too much.

i dont have adb access to verify anything yet, but here is my line of thought.

the recovery binary, generally stored in /sbin/recovery won't really have a stamped version number on it, although you might be able to strings the binary for a version number, which could be executed by a .sh script called by the updater-script and if the script fails, you can stop the update and print an error message.

another thought, the kernel the recovery binary is housed in that is flashed/stored on the recovery partition won't really give much indication as the kernel will probably always be the same kernel version (2.6.35 or whatever is easiest to build for device support), but its compile number might increase, assuming they didn't just merge a new /sbin/recovery binary into the ramdisk and merge with an existing zImage (which could happen).

I've seen manufacturer OTA updater-script files and even cm7 verify device product.model using assert and getprop to confirm the correct .zip is being applied to the correct device before allowing the ROM to be flashed. any official OTA should have this assert getprop command at the top as well as any cm7 .zip.

unfortunately none of those methods or approaches will tell you which version of recovery is being used as twrp, amon and koush all use arbitrary (only really internally significant) version numbers for their recoveries.

on a more positive note, it is possible to test for some types of support in a recovery before allowing an updater-script .zip file to be loaded.

in an effort to better understand and perhaps take an alternate route to provide a solution, what are you trying to accomplish, i.e. what type of support are you requiring from the recovery?

it should but i can't prove it w/o adb access. i'm pretty positive manf OTA .zip files and cm7 .zip use assert(getprop(ro.product.model="supersonic")) etc to check before they allow the .zip to load .. but i'm thinking ro.product.model should be pulled from /system/build.prop which might/might not be mounted in recovery mode when the .zip is being loaded or stored else where when the updater-script is being executed?

should be easy enough to test with adb access to recovery ....

EDIT: adb access now:

cwm recovery on evo 3d, getprop is not setup in the shell and does not work.

taken from the NS4G OTA released a week or so ago:

assert(file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/sojus/crespo4g:2.3.4/GRJ22/121341:user/release-keys" ||

file_getprop("/system/build.prop", "ro.build.fingerprint") == "google/sojus/crespo4g:2.3.5/GRJ90/138666:user/release-keys");

assert(getprop("ro.product.device") == "crespo4g" ||

getprop("ro.build.product") == "crespo4g");

if the call to file_getprop mounts /system, then the second call to getprop should read from the same /system/build.prop. otherwise the stock recovery would have to support the getprop command, which i doubt as the first command differs from the 2nd.

hope that makes sense. looks like assert(file_getprop( is your best bet .. and that doesn't verify recovery version. if you can provide more information around what you're wanting to do, perhaps there is another way to approach.

hope that helps!