Update documentation to reflect this is 2.2.0 stablisation

Author: mubes

README.md

@@ -8,7 +8,7 @@
 
 ![Screenshot](https://raw.githubusercontent.com/orbcode/orbuculum/main/Docs/title.png)
 
-This (orbflow) is the development branch for V2.2.0. Development is generally done in feature branches and folded into main as those features mature, but the changes in orbflow are significant and disruptive, with limited user visible benefit, so we want to keep them off main for a little while longer.
+This is the branch for the development of Orbuculum V2.2.0 which is currently in feature freeze and Beta test. Bugfixes for 2.2.0 will be done in this branch. Development is generally done in feature branches and folded into main as those features mature - that will be post 2.2.0.
 
 Version 2.2.0 builds on 2.1.0 and adds several new CPU families, improved client application handling and the start of ETM4 support. Stats and timing are also much improved and the whole communications subsystem has been simplified and streamlined. Most importantly though, we have moved from 'legacy' protocol (basically, the exact same protocol that flows from the chip) for communications to 'orbflow' protocol. Orbflow protocol is an extensible packet oriented protocol which provides a more compact representation of the probe data. By default orbflow is used transparently between orbuculum and client applications. If you have an ORBTrace 1.4.0 or higher version then it is also used for communication from the probe to orbuculum. If you have your own legacy applications, or a version of ORBTrace less that 1.4.0, then the system will fall back to legacy protocol transparently. You can have a hybrid arrangement where some clients use legacy protocol and some use orbflow no problem.  As you might imagine this can quickly become complex so please yell up if any edge cases don't seem to work correctly!