Changes from v2.8
Vectors are no longer limited to 2 billion elements as they now have a 64bit length.
The default integer is no longer 32bit, it is 64bit. i.e. in k/q 0 is short hand for 0j. 0i represents a 32bit int.
You should almost never see type i, just like we never see type h.
The return type from count, find, floor,... are now 64bit ints (q longs)
Schemas and q script files should be fine.
There will be some NUCs when performing operations like 0^int() as this now returns a vector of 64bit ints. It may be simplest to scan your code for numeric literals, and where 32bit ints are intended to be kept, specify them explicitly as such, e.g. 0i^.... this can be done prior to upgrade and such tokens are compatible with previous versions.
kdb+ 3.0 can read 2.7/2.8 kdb+ file formats without conversion. kdb+ files created by 3.0 cannot be read by previous versions.
Ipc messaging is the same as with previous versions, and no single message can exceed 2 billion bytes. Hence there is no need for upgrading client drivers (c.java etc), and kdb+3.0 can connect to prior versions, however note that some functions may now result in different return types - e.g. counts and i's are 64bit.
Shared libraries that are loaded into kdb+ must be recompiled using the new k header (k.h), and some function signatures have widened some of their types.
When compiling for v3.0
define KXVER=3 e.g. gcc -D KXVER=3 ...
At the moment there's no need to recompile standalone apps, i.e. that do not load as a shared lib into kdb+. For those just continue to compile with KXVER undefined or =2, and bind with existing c.o/c.obj etc.
kdb+v3.0 has support for websockets according to RFC 6455, and has been tested with Chrome and Firefox. It is expected that other browsers will catch up shortly.