At least .78 since some important bug and security fixes are included.
It's a matter of development style: SoC manufacturers design new hardware and need drivers for that in the kernel. They take what they get for free (kernel sources from kernel.org and a build toolchain from linaro.org -- maybe they choose to fetch the kernel also from there) and start to fiddle around with the code. Actions Semi obviously decided to go with 3.10.37: http://releases.linaro.org/14.04/components/kernel/linux-linaro-stable-lsk/
So obviously work on the ATM7059 (the SoC also called S500) started after April 2014. Then they hacked together what's needed to provide something useable for their customers (manufacturers of Android tablets, OTT boxes, whatever). Since noone of these customers gives a sh*t about the kernel version or security implications due to unfixed bugs, noone will have a look into the kernel sources and noone really cares what's therein only as pre-compiled binary BLOBs (the 2D/3D and video acceleration stuff for example). I would believe the kernel sources are part of the commercially available SDK only to exchange such stuff as the boot logo (Actions even chose to hack the linux kernel sources to not use logo_linux_clut224.ppm but logo_actions_clut224.ppm instead).
If you have a look at the quality of the scripts inside the 'SDK' you'll realize that these are just quick&dirty hacks without any error handling and so on. I hope the code quality of kernel code adjustments made by Actions is better.
Anyway: That's the reason we're still at 3.10.37: Since Actions never tried to get support for their hardware into mainline kernel (which would require a totally different development style than just hacking around until the hardware works somewhat) the code base that can be used for ATM7059 and the official 3.10.y kernel version diverge more and more with every kernel release upgrade.
We or lets better say Actions would only be able to be on par with the official kernel sources if they would maintain all the stuff they hacked together as a clean but very huge patchset, that has to be applied to every single 3.10.y version after release followed by a huge and time consuming set of tests followed by a round of fixes since changes in the official kernel doesn't match the patch's requirements. None of the SoC manufacturers will be that moronic and even try that since it's a waste of ressources (and in the past nobody cared since the kernel was 'just' central part of Android).
This 'take from the community and do quick&dirty hacking to support your own hardware' style led to being cut-off from every newer kernel release. So to get at least some severe bugs fixed you would've to choose a specific 3.10.y version and try to apply everything they changed back with 3.10.37 again. Depending on whether they worked internally also in a sane way with Github or just followed the same quick&dirty style they used in the SDK's scripts everywhere this can require a huge amount of work.
So I doubt we will see a kernel upgrade that soon.
The last thing we will see is mainline support. But exactly this would be the basic requirement to always use the latest kernel version since unless the drivers for the hardware aren't included in the official kernel sources you would've to apply all necessary patches for the hardware again and again to every new release. Which won't work since sometimes things break.
And the most important part that prevents Actions Semi's SoC going mainline: Proprietary driver stuff necessary to use HW acceleration. Who knows whether they at Actions Semi have sources for PowerVR or just BLOBs suitable for a specific kernel version? So even when the (yet non-existing) community would start to write hardware support for Actions Semi's SoCs from scratch: What would be the benefit when HW acceleration doesn't work afterwards? This and USB3 are the only two advantages of the S500 when it's about to use this thing with Linux.