This really bothers me.
This should not be added in any 6.x releases. This is not a "small" new feature as it probably required serious changes to the firewall coding. Stuff like this needs to be fully tested before hitting the actual release chain. The 6.28 release broke a LOT of stuff, and now 6.29 is supposed to fix everything AND add this major change in?
You guys need to separate properly between fixing/stabilizing the firmware, and THEN adding new stuff. Don't do both steps at the same time.
This isn't/wasn't a requested feature either. Where did people ask for this? There are dozens upon dozens of feature requests that are active. Why not address those first? This is an "ok" tool, but we can live without it compared to some other feature requests that I would say are much more needed (And some of which are much smaller to build than this).
MT guys, you were getting much better at your development releases, and now you are starting to slip again. Stop.
we (users) are our own worst enemy because we are constantly begging for new features and then rant and rave when those new features break things.
While it's true that people want new things, and I do agree that we rant and rave when those things break stuff...
1) Mikrotik needs to start freezing firmware, and flat out say "Too Bad!" to new features at some point. There's no point in chasing new features while leaving a trail of destruction behind you. I'd rather have a stable router with limited functionality, then a Swiss Army Knife that can do everything but break every time I try and use it, or something I'm afraid will explode every time I make a config change. This would be an acceptable process if MT had a proper open workflow system for dealing with bugs (A forum isn't it!), and could deal with them in an open and timely manner.
2) Mikrotik should actually add in requests that are requested. Fasttrack was not requested anywhere. Yes it does help performance (Many are complaining about that, especially given the inflated numbers that the CCR does not live up to) but it still doesn't address the core problems behind performance in the first place. It's a band-aid.
You don't get this with major vendors. You get bugs, don't get me wrong there. But the stuff is usually tested better, and there are proper support/workflows in place that make it slightly less painful when something does happen. Most major vendors (That I'm aware of anyway) separate the firmware chains between new additions and stability fixes. We don't even have a proper beta chain here. The "Stable" is the beta. There should be a closed beta group for testing firmware before it gets released first. (7 does not qualify. 6.x needs this... If it goes live on the website, it needs to pass through a test user group first. Ubnt even does this, so it's not like it's financially restrictive, or a byproduct of being a "small, low cost" company or product.)