Does MikroTik have a written Release policy? and End of Life (EoL) policy?
I would request that these wind up in prominent, authoritative locations—as I’ve yet to find them, on the homepage site or atlassian wiki (or old mediawiki).
It seems reasonable, or reasonably easy, to explicitly disclaim which products these cover. I use just RouterOS and the mobile app, but SwitchOS (SwOS) and the Dude, seem reasonable to call in by name when describing release and end of life policies.
The device has an operating system preinstalled and licensed. No separate purchase is necessary and the product is ready to use. The device includes free software updates for the life of the product or a minimum of 5 years starting from date of purchase..
I just installed 7.20 on RB953 that’s at least 10 years old, as proof. Now I’ll offer that device with 16MB flash might not be best choice for longevity, but MikroTik still has keep RouterOS to fit.
Now Dude is different story. It also still works… but there are been no changes. MikroTik has alluded to a new “controller” in future, but I’m not sure there are clocks in Latvia.
IMHO there are two possible implications in the quoted sentence:
One can get software update packages for free during stated period. After that those packages may be available for a fee.
MT is committed to providing software upgrades for the stated period of time.
IMO upgrades are more than security fixes (which is all that some vendors provide).
For some vendors, operating in low-end market (budget priced SoHo market), only the first bullet is generally true (I've owned cheap devices for which software upgrades were rare and only occurred soon after product launch).
And for some vendors, operating in high-end market, only the second bullet might be true (vendors require some kind of software/support subscription for users to get software upgrades after a short initial period after purchase is made).
With Mikrotik the decades-long experience goes that both bullets are true.
As to written policies, metioned in OP by @mcint : no, MT doesn't publish any such policies (so they might not even exist ... which would make policy "support until possible" the only existing policy, although it's not written either and is a bit vague as well).
I think that clocks and calendars exist allright in Latvia, only the good Mikrotik guys are trained to either never look at them or simply ignore them.
Here’s a nice checklist of all our recommendations. These are our recommendations - feel free to ignore what doesn’t work for you. Every item is linked to the relevant section in the document below.
Document all relevant information together, accessible to your end-users.
Publish at a stable URL, and make sure this link is not versioned.
Document your release cadence.
Explain all levels of support.
Document your versioning policy.
Demarcate your list of releases between supported and unsupported releases.
Provide the latest version in every support cycle.
Provide absolute dates, instead of relative ones.
Provide complete dates, include the day of the month.
If you have a release schedule image, label it clearly and mark a current date line.
As I compose summary language for the project, I find myself wanting an understand of MikroTik's current, intended release, support, deprecation, or end of life practices, so that I can reliably tell others the same. Including in the context of the open-source normalized data project.
For consideration
Apache Software Foundation Release Policy (https://www.apache.org/legal/release-policy.html). They are solving a different challenge, of clearly coordination expectations across users and maintainers for a whole host of software projects, of different sizes and maturity levels (above some high bar). --
Cisco End-of-Life Policy (https://www.cisco.com/c/en/us/products/eos-eol-policy.html) has explicit milestones and age out dates. Cisco is the juggernaut, and has extensive, remunerative contracts with large enterprises and governments. I think MikroTik wouldn't mind have more & bigger business, and this documents would help sell into these markets.
Juniper Networks Product End-of-Life Policy & Procedure ("EOL Policy")(https://support.juniper.net/support/pdf/eol/juniper-networks-end-of-life-policy-procedure.pdf) includes these definitions & milestones.
Palo Alto Networks End-of-Life Policy (https://www.paloaltonetworks.com/services/support/end-of-life-announcements/end-of-life-policy), with product- and version-specific discussion, including caveat carvouts about contracted support.
Imperva End of Life Policy (https://www.imperva.com/support/eol-policy/) including "Life cycle milestone definitions". Quite readable, succinct, web-native.
I appreciate the affirmation, I too have an understanding of—great brand trust in—MikroTik's ongoing support. However, I'm asking specifically about the policies, as statements and public commitments so that others can rely on it. It's a simple statement from the company to describe existing policies. It's more complicated for me to try to represent to someone else how to interpret MikroTik's passing reference to policies.
But if you are looking for a specific Company statement, you should ask the Company, while sometimes some Mikrotik personnel reads the forum, It Is not given that this happens and that your request Is transmitted to someone that can make an official statement.
You could try writing to support explaining what you just posted.
That’s not true. You can upgrade a version to latest stable.
IDK about the site, but some ways noting things like V6 only receive security updates. And, at present, there is no long term for V7. Additionally, MikroTik support policy is limited to bugs and interop/incompatibility, not configuration help.
That is not certain. There may appear a 7.19.7 still. We just don’t know.
About firmware support in general: where most router manufacturers generate a firmware specific for each device, and they end support at the EoL date of that device, MikroTik has always provided generic software only tied to the CPU architecture of the device.
While it could happen that an entire architecture that appears only in devices not sold for at least 5 years is abandoned (e.g. PPC, MIPSBE, TILE), it does not appear that individual device support is abandoned not even long after EoL.
I recently upgraded a router from 6.x to latest stable, and even in the 7.13 range, my attempts to skip minor versions in the sequence were met with same response as updating directly to latest stable, namely a quiet no-op.
MT set things up so that ROS 6 won't upgrade to ROS 7 unless one selects channel=upgrade (because there are quite a few "breaking changes" between v6 and v7). I'm not sure that's still the case though.
There was a discontinuation in packages for wireless/wifi between 7.12.1 and 7.13. Upgrader in 7.12 can figure out the change, earlier can't. So if you're upgrading ROS using built-in upgrader, you'll have to upgrade to 7.12.1 first and that one will allow you to go directly to latest stable (7.20.1 at the time of writing this post). And that includes upgrading from v6 (which is, regarding wireless drivers, similar to v7 up to and including 7.12.1).