We have been running 08.0.80c, and it has been perfectly fine.
For ANY ICX 7000 series switches, I would get off 08.0.30. I leave that codebase for the older ICX 6000 series devices at this point.
That said, I am NOT 100% sure what happens if you do such a massive upgrade all at once... I do not know if the pre-parsing scripts convert everything from all the way down to 08.0.30 codebase or not.
What we did was upgrade years ago to 08.0.61a a long time ago.
What changed was the Access-Lists, which were converted to use sequence numbers.
Before they looked like this:
access-list 1 deny host 10.157.22.26 log
access-list 1 deny 10.157.29.12 log
access-list 1 deny host 10.1.2.3 log
access-list 1 permit any
I do not have one in front of me, but later it was something more like
ip access-list standard 1
sequence 10 deny host 10.157.22.26 log
sequence 20 deny 10.157.29.12 log
sequence 30 deny host 10.1.2.3 log
sequence 40 permit any
It also updated the LAG configurations such that they now show up with actual lag interfaces, which are software virtual interfaces similar to a Cisco Port-Channel. You no longer use the keyword "deploy" and they depreciated the "primary-port"
*************
Personally, I would avoid the 08.0.60 code and jump to the latest 08.0.61 for your first upgrade, because I know it will work.
After it's working, I would do a "wr mem" to copy the new running configuration to the startup configuration. My reason for avoiding 08.0.60 code is that on several of the switch models it did not support stacking, and they did not even have a layer-3 build of it for quite a while. That said, if I recall sometimes 08.0.61a would not sync NTP to my Cisco core. It gave some strange Straatum error. Regardless, this was never any issue in 08.0.70 or later builds. More likely than not it was fixed in later builds of 08.0.61 as well.
*************
08.0.70 builds turns on inline-power by default, and it even upgrades the PoE firmware automatically on supporting hardware.
08.0.80 builds depreciate dual-mode, which is how you set a native-vlan on an interface.
The same rules apply that any give Ethernet_II frame can belong to only one VLAN, but now, you can take an interface "tagged" in as many 802.1q VLANs as you like (i.e. trunk port with allowed VLANS), and you can untag it to one (1) VLAN of your choosing to specify what happens when an untagged Ethernet_II frame comes into that Interface as well as transmit frames without the 802.1q frame on that interface for that VLAN.
Simply put, the configuration on 08.0.80 is streamlined. Have no fear though, it will pre-parse and convert the configuration without failure.