My 2 cents ![]()
If it is true that v7 should not be used in production, why then do have a chateau that cannot be downgraded to v6?
Chateau cannot run on RouterOS v6. It is shipped with v7.0.X (stable), which is different than 7.1betaX (development). Historically, RouterOS is released per platform (x86, arm, mips, tile, etc.). Unfortunately, there is no stable per-platform ROS v7 available yet. So the decision has been made to stabilize per-device v7 firmware. RouterOS v7.0.X has the same release procedure as the current stable v6 (6.48.X), but it is limited to specific devices only. Some “v7 beta features” like routing filters have “sneaked” into the release, but that’s a different story. By the way, some other vendors do per-device firmware since day one.
Regarding v7.1beta, I think the appearance of “beta” in the name is confusing. There are two different release channels: Testing (currently, v6.49) and Development (v7.1), both having “beta” in the name. However, the Testing channel is way more stable than the Development. The term “beta” from traditional software engineering fits more to the Testing channel. If we had renamed releases in the Development channel to v7.1dev6, it would cause less confusion.
One step forward in learning, one step back - what is Chateau???
Now I’m on office and check this…
1Gbps full duplex, radio-link 2Gbps half duplex
It’s very interesting. Where to download stable 7.0.x version for Chateau? If it is stable, does it mean SUP-37062 issue is not exists in this version?
If we had renamed releases in the Development channel to v7.1dev6, it would cause less confusion.
A very welcome decision.
Sorry, but what are the properties that define a “stable” state? Also, I need to correct your statement, it arrived with v7.0beta6 firmware. I mean, it was fantastic to be a doorstop, but I expect a bit more from a new device with Mikrotik name.
What does it mean? You mentioned above 7.0beta6 was stable, it means (for me), it implements all expected features and stable enough to have minimal support request. But even the whole thing far from the “beta” status, I don’t even call 7.0beta6 as “beta”. Furthermore, 7.1beta6 seems to be an alpha release which doesn’t even have over the planning phase. So, back to the question, if you rename 7.1beta6 7.1dev6, does it change the fact you released a device without working essential functions and one year after the release you name the initial firmware “stable”?
Thanks for that, where can I find V7.0 for the chateau to reflash?
When can I get the v7.0.x stable for the chateau? the 3 I just received didn’t have a stable but a beta :S
The big issue with mikrotik is that they know that they break many features in each release. I they simply mention what’s notworking and known to them it would be of great help.
If we know something is not working, it is written in the changelog as a warning. We don’t intentionally break anyone’s devices by hiding stuff like that
If we know something is not working, it is written in the changelog as a warning. We don’t intentionally break anyone’s devices by hiding stuff like that
Why did you bring this up? I do not believe we have an idiot here who thinks you work against yourselves, our problem mainly:
- you have a product without stable firmware
- there are multiple problems with the actual version, but these are understandable on a development path, but without knowing where are we at in the development or more like when do you plan to consider the actual status feature complete a bit problematic.
- for above reasons, nobody knows when it is worth to try a new version if the person not intended to test only want to use the device
I believe a simple statement about when do you expect the 7.x milestones in your actual view could normalize this situation, it also can be changeable, but it would give information for your customers how you think about 7.x actual state and when do you expect to release as GA. /of course, it is only my opinion/
I am replying to the poster above, who said, we are hiding known issues intentionally
And Ubiquiti, for exalmple, has AirFiber 60-LR with 2Gbp/s link but only 1Gbp/s Copper ethernet...
This is actually a good thing for the most part. You ideally want your air transmission rate to be higher than your actual ethernet throughput rate to allow for a more consistent experience when the conditions worsen and to cater for things like silent re-transmission
That data rate is never attainable in the first place (always some loss) however if you have to retransmit ~10% of your frames you can do so very quickly and seamlessly. That way a ~1gbit/s transfer doesn't even notice that retransmissions have occured, it continues on nicely at the full speed as it can retransmit and 'catch up' before the frame buffer empties
However if you implement a 2.5gbit/s chip and lets say you did get 2gbit/s of throughput. Periodic retransmission would see your speed briefly dip and your latency increase
You could always artificially reduce the speed to achieve the same result, however the simple reality is 2.5gbit/s adds quite a bit to the cost at the manufacturing layer, which is passed on to the consumer at a much higher price. It just isn't worth it if you are buying 200x of them and can only really use a small boost in speed ~10% of the time at a significant price premium
This thread should be closed. It does not longer discuss “v7 launch date”
MT never have a fixed “launch date”. It will be released when they think it stable enough, sometime in future.
This thread should be closed. It does not longer discuss “v7 launch date”
MT never have a fixed “launch date”. It will be released when they think it stable enough, sometime in future.
Don’t quite understand, a few people are offing this topic (like you), but 2 days ago, MT officially announced 7.0.x as stable, you don’t even follow the topic, but you want to close it. What is your real problem?
Did you get a date?
PS no need to quote the whole post above you,
but 2 days ago, MT officially announced 7.0.x as stable, you don’t even follow the topic, but you want to close it. What is your real problem?
Version 7.0.x as stable only for the Chateau not for any other device in the MikroTik portfolio … plus this was not an OFFICAL release statement JUST a FYI.
IMO, its still a long way to go for all other models that may be capable of running v7… I suspect it will be stable for all other CAPABLE devices end of this year or spring of 2022.
IMO, its still a long way to go for all other models that may be capable of running v7… I suspect it will be stable for all other CAPABLE devices end of this year or spring of 2022.
I do wonder how much heavy lifting remains to be done on V7, and how much left is just cosmetic/config interface… They sure are working hard on it - every changelog shows work done at a very low level, and this is both hard and slow going.
Too bad we don’t have a chart with milestones, or something like this, so we could have a better idea…
MikroTik want work without milestone.
Why must be obliged to work like some others expect?
The things are ready when done. Stop.
Too much pressure do not give anything good.
If that delude your aspectation, simply do not have one.
If we know something is not working, it is written in the changelog as a warning. We don’t intentionally break anyone’s devices by hiding stuff like that
You got me wrong. I guess you guys tested filter before releasing 7.1beta 5 no where it was mentioned that filters are not working. After opening support ticket I was informed that filters were not working and it was known by support. It would be fixed in next release. So why was it not mentioned in the changelog.