Well, 7.1.5 was definitely offered in the long-term channel in early June. This is why I installed it.That is correct, there NEVER HAS BEEN a version 7 Long Term software/firmware offering yet.
Furthermore the latest Stable Version is 7.4, if you want use vers7.
Well, 7.1.5 was definitely offered in the long-term channel in early June. This is why I installed it.That is correct, there NEVER HAS BEEN a version 7 Long Term software/firmware offering yet.
Furthermore the latest Stable Version is 7.4, if you want use vers7.
Sob, you have such little faith in the software processes of MT LOL. Your theory (a very poor one) on how or if they have a process for deciding long term versions is the stuff of trashy tabloids.It's simple. RouterOS has different channels, where long-term should be the most stable of all. So if 7.1.5 was there for a while (which many would agree was premature) and someone installed it, it may be a little disappointing to see that MikroTik changed their mind and now there's really no long-term version yet. First part of it is "so what the hell is the thing I installed?!". Second worry can be about updates. Those are generally good, especially security ones you'd expect in long-term branch. So someone might fear that if there's bug in this "fake" long-term version, there won't be fix for it. But I wouldn't worry about that too much. There's not that many security bugs in the first place. And if some really bad one came up, MikroTik can easily release something in long-term channel. It's not like there's some rigorous process for that, they basically promote some version to long-term from time to time, after the base version wasn't too disastrous for a while. And eventually there will be "real" long-term version to replace 7.1.5.
Should be.Is v7.4 stabler than v7.3.1 ?
Should be.Is v7.4 stabler than v7.3.1 ?
Oh my gosh... so what is the current version?Yes, this will happen, when there is a stable enough version.
No, it isn't... but is it a race?Sorry Joseph, is this your first time using "software"?
No need to fuss around, it's got a name: Becherovka... cheap Czech liquor ;-P
Okay everybody knows the baddest liquor in Europe is zganje !
...Well....by mkx » Wed Jul 20, 2022 5:26 pm
I'm sure some slightly more recent version (e.g. 7.2.3) will appear as long-term soon enough.
There's a dot misplaced in my (quoted) post ... what I meant was 7.23...Well....by mkx » Wed Jul 20, 2022 5:26 pm
I'm sure some slightly more recent version (e.g. 7.2.3) will appear as long-term soon enough.
For me a long-term for v7 is v7.7, with 2 BGP full tables and 2x 2Gbit lines do not give any problem....What will change if we rename any random release to long-term? It's only a name. If you think 7.8 is stable enough to be called that, just use it, no matter what it's called
C'mon man! I can't believe you just wrote that! Please tell me you had a gun pointed at you and you were forced to write that!It's only a name. If you think 7.8 is stable enough to be called that, just use it, no matter what it's called
I agree, without a shadow of a reasonable doubt.Sorry to ruin your dreams, but for most software, there is no such scientific process. It is just a matter of "less known bugs than X"
YES! Please, as soon as humanly possible, STOP adding features and just fix everything you are aware of not working and give us a very reliable long term release. You can skip all additional packages from this long term release, we don't need zero tier, wave2 or rose support in the first long term release, in fact I imagine that most of us waiting for a long term release would prefer if support for these packages didn't even exist yet in the long term release.Yes, at some point MikroTik should stop adding features to a selected version, and then there should be some stabilized point releases after. At least this is how it was before. We might change something in future. Edit: yes, you seem to have noticed that v7 is a bit different, versions come out much faster, changelogs are bigger, but there are no long-term and no point releases. It's a different approach. Maybe we need to drop long-term, it is not decided yet.
my point is that no features should be in long term until they have survived multiple stable releases without any additional bug fixes. Wave2 does not currentyly meet that criteria, though someday it certainly will, and until then it should remain limited to RC or Stable releases only. Long term should be absolutely the best most reliable and bug free code, nothing less. If any feature is still being developed and improved then it should be left in either rc or stable depending on a particular subset of the features and how well tested they are. I'm not saying wave2 should forever be kept out of long term, only that I think it's entirely appropriate for long term to have fewer features available for it while those features are being further tested and refined. There should be a tradeoff of delayed feature support in exchange for exceedingly stable long term releases. Trying to run a still being developed feature while also expecting that to work in a build tree that is supposed to be extremely reliable and stable is a textbook definition of an impossible situation.We do need wave2 in v7 long-term ... because a few device models require it to run their wireless interfaces. It doesn't matter that it's in separate package.
And similarly your post contains other BS.
there's currently no long term version at all for v7, and the last v6 long term build was released in December of 2021, which one could argue is long enough ago to say it's no longer current enough to be counted (especially as it contains numerous bugs relating to loading of branding files). What I'm advocating for is trying to get to a v7 long term build as quickly as possible, but not by just slapping a long term label on something already existing just for the sake of it. Disable whatever isn't worthy of the designation long term and release whatever is. For many of us most of the additional features or packages are not used at all where we care about a long term build deployments, so delaying a release we can count on to be bug free for functionality that we don't use is annoying.To reply to a long post with short: there is no long-term version which contains wifiwave2. And according to previous post, there shouldn't be one before wifiwave2 gets very stable.
you could not be further from correct. For one, I run the management of the company therefore it is me that cares about stability and reliability of our routers, and I absolutely care about the reasons I stated above. If you read what I'm advocating for, it is to once again release a long term build that only contains well tested and proven code. That definition means that new functionality should not be included into the long term release as they are not yet well tested and proven. As an example, wave2 is very much still in development and 7.9 stable that was released today included 5 new additions and 11 fixes or improvements to it, that is far from stable and proven, however regular wireless had no changes in the changelog, I would certainly consider that stable and proven. Those of us that install MikroTik as business critical infrastructure care more about stability and reliability then we do about new features, so we would prefer to see a stripped down version that has fewer features but contains fewer bugs in the code (including bugs in subsystems we aren't using, because those could still lead to security or stability concerns). Look at the problems that came up in 7.8 with SFP compatibility, had we deployed 7.8 we could have had devices go offline that operate 2,000 miles away. When we update our routers we can't afford to have a new bug that was introduced in the latest release cause interfaces to go offline!It seems to me that you're advocating for a "politically determined" declaration of some version to be long-term. Just because you have to (management of your company is asking you?) install a new LTS version of OS to whatever infrastructure you've got and MT didn't deliver one for quite a while. And you don't seem to care about actual reasons for this.
If you only care about version which didn't change for a while, use 7.4.1 ... it's a "dot" release, it was released in August 2022 ... and you're free to use it for next few years.
I don't see any added value in MT declaring it LTS as MT doesn't seem to be willing to dedicate any resources to maintaining some v7 LTS due to rapid functionality development currently going on in v7. And a lot of it has to be done, arguments that v7 has to offer at least same functionality as v6 are very well funded IMO (annd currently v7 still lacks some).
If your motivation in advocating for a v7 LTS is not what I described above, then ... please explain what is it. What is wrong with 6.48.6 as LTS?
It's very simple, some of us want a build that is very well tested and I for one am perfectly happy to forgo new features and added functionality for however long it takes to get them to be very robust and reliable in exchange for having a version that we can deploy to thousands of devices without needing to worry about what might break.What's new in 6.49.7 (2022-Oct-11 17:37):
*) branding - fixed execution of "autorun.scr" file when installing branding package (introduced in v6.47)
sorry, somehow missed this thread had replies... maybe a new BB isn't such a bad idea?As you yourself wrote, v7 isn't stable yet (because it lacks functionality) so it can't be made LTS. And you yourself wrote there's hardware that requires v7. Combine that with some of ROS paramounts (same feature set on all devices, same ROS version for all devices) and it's clear that what you're advocating for is very probably not gonna happen.
I wouldn't like to guess which of v7-only devices is commercially more important to MT in short term, but if it's SOHO wireless routers, read ax line, then stabilization of wifiwave2 "optional package" might be more important than whatever is most important to you. And at the end of the day (or decade) all of ROS v7 parts and functions need to be in pretty good shape before declaring (and commit into) LTS.