Release policy & EoL policy?

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.

It’s at the bottom of most/all the product pages:

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..

a minimum of 5 years starting from date of purchase

Hm, that logically means that any SKU is guaranteed to receive updates for five years after the last of its kind is sold?

There are devices 10+ years old still able to run most ROS7 version...
(not always recommended but they can).

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:

  1. One can get software update packages for free during stated period. After that those packages may be available for a fee.
  2. 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'm not saying the following is true for Latvia .... but some countries go back in time so in those places, future might not happen for a looong time.

You can go Back To The Future, it seems.

Just need a Delorean ...

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. :wink:

Purpose

I ask because I am including RouterOS in https://endoflife.date/ for succinct, standardized reporting of latest & supported versions.

MikroTik already has practices in accordance with most of their recommendations

Checklist

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.
  • MicroChip End-of-Life (EoL) Policy (https://www.microchip.com/en-us/support/quality/end-of-life-eol-policy)

That’s a direct answer, if limited. Thank you!

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.

Excellent point, thanks for nudging me straight, as a request it would languish here.

For my own amusement, others' curiosity, here's a preview of the support page, temporary netlify build artifact.

On reflection here, it seems like it would be more accurate to say only the stable and long term version "heads" have support

image

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.

Correct. Because none of the 7.19.x, 7.18.x, 7.17.x listed will get the fix for CVE-2025-10948.

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.

Only MIPSLE and x86 for RB230 are abandoned

And SwOS and SwOS lite?

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.

There are a couple of major versions you cannot skip, but you do not need to skip minor versions.

Check for space on the device and perform a netinstall to clean things up.

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).