The thing is that stable release in software development is most commonly RC with all features expected in final release already present and tested in alpha and beta phases and going through final testing and quality assurance cycle ensuring that software is bug free or that the bugs left are non issue (cosmetics etc). Of course all the bugs which occur in rare and specific cases would never be found but that doesn't mean you should skip testing and hope for the best...
Only after that is software released as production of GA, and that final stage is something MikroTik is obviously not ready or able to perform and therefore are right to call these releases stable meaning they are really final RC that users should do the final testing themselves... after all there is no such thing as free lunch and RouterOS is more or less free to use, at least for now...
The beta and rc versions receive less testing because there is a smaller group of users that install that, most wait for stable and then immediately install that. Result is that stable has a much larger group of users and uncovers bugs that beta and rc never uncovered (or that were not reported).
As I said RC is most commonly referred to as stable release because no new features are added and code base is stable meaning nothing is changed unless some show stopping bug is discovered in which case it is either fixed if it is relatively simple thing to do or may even be reverted back to beta or even alpha if more radical changes are required, on the other hand users are never the only one expected to do the testing, they are well appreciated aid but developers are supposed to devise their own testing frameworks...
That's how it seems to me. All the package files have some additional data, but for most of them it's just some metadata plus signature. Except for the base routeros package - there it seems like the entire kernel + initramfs is in this part as well...
Anyway, just thought I'd share.
I believe there is a hint of sarcasm.
But I don't see any untruths there.
It reminded me a lot of the twelve truths of the internet.
https://datatracker.ietf.org/doc/rfc1925/
I think it's a way of demonstrating that on the MikroTik team some do believe and even sell as truth some statements, which is not exactly what happens.
Sometimes, to get a good "Anything", all you have to do is spread the truth across the wall with a dose of humor.
P.S.: I still dream of an Eleanore V8. To me, it's like a unicorn.
Also, sometimes, Dukhat should be invoked:
https://jdebp.uk/FGA/dukhat-on-foolishness.html
Thank you for letting us know. I believe we have figured out the issue. It seems to be misconfiguration together with switch QoS changes.
The missing access to switch and failing STP is a result of switch1-cpu port being configured with "offline" tx-manager (/interface/ethernet/switch/qos/port). The built-in "offline" tx-manager makes the switch port (including the switch1-cpu) with minimal buffers.
We will update RouterOS so that users cannot set the switch1-cpu with "offline" tx-manager setting. It is a misconfiguration which should not happen.
And there is an issue with offline tx-manager. Even when "offline" tx-manager is set on any switch port, it should still allow queuing at least 1 packet to avoid complete packet loss. This is the reason why you lost the access after the upgrade from 7.19.2 to 7.22. The built-in offline tx-manager in 7.21 has been updated too restrictive (it does not allow even 1 packet to be queued). We will fix this as well.
Interesting case, but I canāt imagine why somebody sets cpu-ports as āofflineā in tx-managerā¦
It must be from docs:
There was a command to use "offline" on non-running ports. In case you copy/paste the command in older ROS versions (7.17-), it will also apply to switch-cpu. Changed the docs, and added a warning regarding switch-cpu port.
You are correct, but please stop blaming the end user.
Product testing is the responsibility of Mikrotik.
Allow me to disagree: it's both sides' responsibility.
Putting something that's been out for five days into production (and not one at a time, but all together at the same time) isn't healthy at all.
And I'm talking about ANY brand, not because it's MikroTik...
No, itās not. User pays Mikrotik for the product.
If you donāt have enough resources to perform adequate tests before releasing the product you should:
A: Raise the price of the product
or
B: Admit you donāt have enough resources, so end-users make decisions accounting for the risks of product not being fully tested.
In either way do not call the product āSTABLEā it the product has not passed all tests (as you defined them in your own post).
As said: rename channel to "current". all "this is not stable" arguments void. easy fix.
Why do you write like this?
MikroTik has thousands of users who deploy the software in production as soon as it's released.
They do so for free at their own risk.
The ones posting here on the forum are only those experiencing problems, or with an unusual configuration or probably a configuration "override",
the others who have everything working don't show up here.
I āwrite like thisā because I see users being blamed for experiencing the issues.
Issues that result from different understanding of what a finished product should look like.
As proven by the issue reported by dockarl. It was just a uncommon misconfiguration.
But dockarl said he had labbed the RC versions.
How could he not loose connection on 7.22rc in lab? When the issue was introduced with 7.21 already.
Probably the lab equipment was missing the copy pasta soup config
Yes, lab most probably did not reflect the exact config of production equipment.
Do install bits get tastier if left one week on the Download server cellar before being installed ?
A week or one day after the release is published by supplier, it must be good to go.
If Mikrotik feels like there are too few testers testing the rc to discover all the issues, then they should add more internal testers.
To be honest this particular case is very difficult to detectā¦