To me it seems like the long term channel has been little more than “old and proven version”. In general, I think “long term” usually implies long term support, ie continuing to receive bug and security fixes for duration of the “term”, without receiving new features. There has not been an abundance of patch releases on the long term channel over the last few years, and certainly not within the same “minor” version.
As for version 7, it seems to be so heavily in development still that I don’t know whether a long term release makes sense at this time.
well, development of ROS 6 seems to have stopped by end of 2021, which explains why there is no need for new bugfixes for the long-term: because no new features have been added, most bugs were already fixed in the latest 6.48.6. But it is still fully supported, from the public info available.
As you say, ROS 7 has major changes compared to ROS6, even in terms of performance, showing that there was heavy development involved (maybe almost starting from a blank sheet).
Well, let’s hope we’ll see a long-term ROS7 published in the near future…
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.
The concept and strategy behind Long Term releases being extremely stable and well tested are very important to many of us. We sell a service to customers, the customers do not care what version or platform we use to deliver that service, they only care that it is reliable and doesn’t break. Infrequent release of updates is actually a plus for uptime. What we find incredibly frustrating is when an update comes out that introduces new features that we aren’t using, and those features likely have their own bugs in them, but problems existed in the previous build are not yet fixed.
Please continue to develop your new features like Rose & wave2 in the RC build releases, but equally please don’t even release them for stable releases until you have added all the functionality you want to and are ready to focus only on fixing bugs. At that point in time when you feature lock a new function then you can release that new package for a Stable build, and transitively you should only be releasing a new stable build once all packages included / available for it have been placed in feature lock. New packages & features released to a stable build should be tested by you and devoid of all known bugs.
Once a new feature has gone 2 or more stable releases without ANY bug fixes, then and only then that feature should be included in the next long term release. If you only release 1 or 2 long term releases per year we would be thrilled. We don’t want frequent new long term releases, we want GOOD releases. Few if any of us wanting to use long term builds are even using things like zero tier, rose or wave2. In fact I’d go so far as to say there should almost never be any additional packages available for a long term release build, if something is not reliable enough to be included in the main OS package it should not be available for long term releases.
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.
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.
Product life cycle should be: Come up with new idea/feature request, develop it internally, once it is devoid of any internally known bugs it gets released in a RC build (either inside the main package or additional package, depending on the feature). Once whatever number of RC builds are needed to solve any bugs that turn up after RC release are gone through and there’s no further known issues there, it gets incorporated into a stable release. This stable release should be devoid of ANY open issues or known bugs in the features included in it, but may still include fixes that were solved since the last RC build which were only tested internally. Once a feature has survived 2 or more stable releases without having any bugs turn up, then and only then should it be incorporated into a long term build. Long term builds may take a year or more to gain support for features like wave2 after they hit the stable release tree, and that should be viewed as a good thing.
edit to add, this also can tie into and help with improved support & documentation, MikroTik could segment the support queues by build, prioritizing tickets for long term builds (aka you get priority support, but only if you run the most reliable and best tested versions), and adopt a policy that all documentation also only officially applies to long term builds, that way they don’t need to update documentation for changes in stable or RC releases (but they should make available unofficial / draft documentation for them).
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.
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.
I suspect most MikroTik installations pretty reliably fall into one of two categories, core router & infrastructure deployments where very little beyond PPPoE / L2TP / IPSEC, queues, routing and firewall functionality is ever used, and the other being edge / end deployments where end user type functions like wireless, zero tier, wireguard, containers, rose, wave2 are heavily used. I’m not suggesting there should ever be two entirely separate versions of RouterOS for these deployments with different core functions, but there would likely be little to no pushback if these additional features took even a year or two longer to make it into a long term build than the stable builds, and when they eventually do they are extremely robust and well tested.
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?
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!
There are several reasons why 6.48.6 is not an option now, Firstly it does not support new hardware (many v7 only devices now), and many older CCR1xxx routers have been discontinued so we are forced to adopt the newer CCR2xxx models for new installations. Secondly there are branding package bugs that were introduced in 6.47 that did not get fully fixed until 6.49.7 which broke several different workflows and processes for us and prevented us from using any versions from 6.46.8 to either 6.49.7 or 7.7 when v7 was finally stable enough to risk putting into production.
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)
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.
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.
You have a good point here: Product lineup strategy has a big impact on the dev of LTE vs. stable releases. As Mikrotik is one of the only companies that has both professional and power-consumer devices in their lineup, the users in both cases may have diverging opinions on what’s most important. Most of the time, end-users want the latest features whereas pro users want stability, stability and more stability (that being said, there are exceptions in both cases.).
Cisco solved this by putting a Cisco sticker on Linksys devices for the end-user market (with a specific, crappy OS), and even SOHO devices such as the SG-series switches don’t run on a real IOS, but are web-configurable only (also crap). Thanks god, Mikrotik has the same OS for all devices, I myself think this is a vers good move!
There’s where having the dev, stable and LTS branches running in parallel has a big advantage when compared to other solutions (for instance, having completely different OSes for consumer and pro devices): One can simply chose his personal “flavour” among these 3 options. And it’s not even an additional effort for MT, as early adopters have more features, and LTS users have a more stable device.
Indeed, as you pointed out, ROS7 is still in development and that’s probably why we’re still waiting for the LTS to be release, but I am wondering how Cisco solves this for instance, as when a new device is released, there is always a stable (main) IOS version available. “T” (=Technology, i.e. new features) versions are added later and eventually make their way into the next main release. But how do they come up with the first main version for a new product? It was the same when they introduced the IOS-XE versions, which are built completely differently than the old IOS. But still, they had a stable version right from the start. And it was really stable, even though there were a few bugfixes follow-ups in the first couple of months, but not that many…
I’m only guessing … but Cisco, with much higher development budgets, can afford to have dedicated team of developers which ports IOS to new devices … as those are being developed. And then they can do lots of in-house testing. So when a new device hits the streets, there’s a LTS version of IOS already available.
BTW, things were not so much different in MT world say 2 years ago. Any new device (e.g. the ac devices, first CCR2xxx, …) came with then latest ROS which pretty soon became LTS. The most prominent development was to squash whatever bugs were with newer devices while older devices were mostly stable as a rock running most ROS releases. New features in ROS mostly didn’t get developed due to old underlying kernel (or so we were told).
Currently things are disturbed due to development of v7 (which itself is not stable) … and then new devices’ bugs are added on top of it. I can understand people who are mighty upset about current situation. But IMO there’s only one thing we can do while patiently waiting for MT devs to finish the ToDo list, and that’s beta testing all new releases and provide quality feedback to them. If some people can not afford to patiently wait for things to get getter, then there might not be too many options to stick with Mikrotik I’m affraid.
sorry, somehow missed this thread had replies… maybe a new BB isn’t such a bad idea?
While omitting the critical nuance of my argument you are correct, and you cannot in the current implementation have a v7 long term as it is in fact still in development, however that’s also missing the entire point and basis of my request, which is to disable, strip, or otherwise render inoperable all the new features and their related modules of v7 which are still under development, and make a release of that remaining highly stable code under the long term branch. Let us users be the ones who decide if those features still in development need to be on a particular router, if we do then we’ll run the stable build, if we don’t need those still being developed features then we have the ability and freedom to run the long term knowing that the functionality it does have is very reliable and stable, and that we won’t be pressured to install an update that fixes one later discovered issue that matters, while introducing 17 bugs in modules that we do not use or care about on that device.
in v6 this was less of an issue even without the long term branch option because you could disable many packages which you did not need on a particular router, like ipv6 for example, and simply not have that code running on the device and the stability and security liability it comes with. For example, in v7 I would love to disable wireguard, hotspot, ipv6, and mpls on my routers that will never use those features and be more protected from any bugs in those somehow affecting a device stability or security. But now that most of the features are baked into the main system package I no longer have that option, hence how I ended up where I am now and asking MT to turn all of the in development stuff off and make a long term release that is free of those liabilities and risks.
I agree about package modularity which was really nice in v6. But I’m affraid it’s not gonna come back any time soon. It was a design choice for v7 which we’ve been discussing back and forth when it was made a fact. And MT didn’t step back from it then so I guess they’ll stick to it for a while.
