Sorry if I missed where this is explained, but I honestly don’t get why threads for previous major releases, like "v7.16.2 [stable]" and "v7.17.2 [stable]", are locked the moment a new major release drops.

I’m pretty sure most users are probably still on older versions, so why shut down discussions about them? This just makes it harder to talk about release-specific issues, which doesn’t make any sense.

Feel free to start a thread about any version of firmware issues.
My impression is that new releases are to gather issues right away for any new release so that the faux Version 7.X.Y.0 can be quickly changed to Version 7.X.Y.1 and then a little while later changed to 7.X.Y.2 relatively stable.

I may have to adjust my thinking a little bit, to 7.x.Z stable, how fast we are 7.18 is amazing!!

If you find issues later, start a thread and send a supout, is the message.

Fixes, updates and new features are added to the newest MikroTik RouterOS version.
It is not possible to release "fixed/improved 7.13" (example), that contains specific issue fix.
That's why the latest release version topic is open and we are looking into it closely for proper reports, that could be fixed/improved in the next stable release.

So what "long-term" means if older versions are out of the changes scope? Could we expect some crucial fixes added or not?

v6.x long-term topic the latest version should not be locked.
Once there will be v7.x long-term version, the same will apply for its topic.

Fixes, updates and new features are added to the newest MikroTik RouterOS version. It is not possible to release "fixed/improved 7.13" (example), that contains specific issue fix.
That's why the latest release version topic is open and we are looking into it closely for proper reports, that could be fixed/improved in the next stable release.

Alright, maybe I’m still missing something or just misunderstanding.

If we take v7.16 and v7.17 as examples, where each version has three point releases (x.yy.0, x.yy.1, and x.yy.2), does that mean that after two patch releases (x.yy.1 and x.yy.2), that branch—along with its forum thread—is locked, no more bug fixes are made, and customers are essentially expected to upgrade to the latest major release instead? In other words, does this mean that right now, only v7.18.0 and the next beta will receive bug fixes?

Maybe I’m overthinking this, but could you please clarify?

EDIT:
Going with the assumption above as the best answer we have for now, which is based on Sergejs’ reply at the end of this thread: "Larsa, yes, your assumptions are more or less correct in the post after mine (then the 3rd player long-term will come into play as well)."

During the beta/rc cycle for version 9.92, some epic/critical bugs will be back ported to version 9.91, and tagged as hotfix releases 9.91.1, 9.91.2, etc.
Maybe you'll get as far as 9.91.35 in theory.
Once version 9.92 is out, no more patches to 9.91 - now beta/dev work is about 9.93, with hotfix backports to 9.92.

Long-term branch (when one exists) is a second layer of the same cycle.
As long as the longterm is 9.85.x it'll keep receiving relevant hotfixes.
Once a new longterm "baseline" is released in form of 9.97.x the hotfixes will start showing up for that next one and 9.85 is no longer supported.

Already waiting for ROSv9

@wrkq I appreciate your take on this, but I’m not sure how it ties into my original question.

I was specifically asking why forum threads for previous patch releases (like v7.16.x and v7.17.x) get locked as soon as a new major release comes out. What you explained about backporting and long-term support makes sense, but it doesn’t really answer my thoughts on why they are shut down the way they are.

Also, you mentioned versions like 9.91, 9.92, and 9.97—are these from an internal system where you work, or were they just random examples? Because my question was about Mikrotik’s v7.xx releases, and I’m not sure if this process applies the same way.

So I’m still wondering: even if older versions aren’t getting fixes anymore, wouldn’t it make sense to keep the latest patch release threads open for people dealing with issues on those versions who can’t upgrade for some reason? Also, I still don’t really get why a patch branch gets shut down. Did MT set some kind of limit on the number of open branches because of resource constraints, or is there a more natural reason and logical that actually helps with upgrade planning?

I'm just trying to understand the logic here..

To rephrase it again: The known enemy is the best enemy.
There are a lot of topics on downgrading to the older versions just to have network in the known equilibrium point even if not all functions work as expected for that versions.

I used the 9.x version numbers as examples to make them look obviously fake, but it was a description of my understanding of MT patch-cycle as-is-today.

My understanding why the old threads are closed:
That those threads are intended as "MT wants to hear you finding issues in this specific version".
Note how often a "Feature X has bug Y!" "This is known since three-releases ago, don't discuss it here" sequence shows up.
(Not to mention general "keep talk on-topic about this version".)

New version is out = MT no longer wants to hear about bugs in previous one because they will not be hotfixing that one anymore = topic closed.
For "user to user support" to discuss workarounds on old unsupported versions there's the whole rest of the forum.

(Again, this is my understanding/interpretation of what-is-happening. I don't have an opinion whether that's the best way to handle it or not.)

To rephrase it again: The known enemy is the best enemy. There are a lot of topics on downgrading to the older versions just to have network in the known equilibrium point even if not all functions work as expected for that versions.

Totally agree with "The known enemy is the best enemy," but I think I lost you on the rest! I’m more focused on understanding how we should deal with locked branches (and releated forum threads) rather than managing downgrades.

New version is out = MT no longer wants to hear about bugs in previous one because they will not be hotfixing that one anymore = topic closed.

Yeah, that’s my guess too: topic closed = branch closed. But I’m still not convinced about the actual when and why. Maybe it’s just as simple as there being no logical explanation.

To rephrase it again: The known enemy is the best enemy. There are a lot of topics on downgrading to the older versions just to have network in the known equilibrium point even if not all functions work as expected for that versions.

Totally agree with "The known enemy is the best enemy," but I think I lost you on the rest! I’m more focused on understanding how we should deal with locked branches (and releated forum threads) rather than managing downgrades.

I mean: lots of users after upgrade have to downgrade to get some crucial funcionalities back and stable enough to be used for production.
As it's said: The better is the enemy of the good.

EDIT: fresh example: viewtopic.php?p=1128741#p1128741

New version is out = MT no longer wants to hear about bugs in previous one because they will not be hotfixing that one anymore = topic closed.

Yeah, that’s my guess too: topic closed = branch closed. But I’m still not convinced about the actual when and why. Maybe it’s just as simple as there being no logical explanation.

As @wrkq wrote: release topics are MT's own topics. After new version is released, MT is no longer interested in discussing previous versions, so they lock topics. End of discussion.
If you want to discuss something about some old version, open your own topic in other forum sections and discuss things there.

I don’t think anyone’s missing your point, but it still doesn’t actually explain why, which was my original question.

The same applies to whether “closed thread = closed branch” also means never releasing any new patches for that branch again.

Larsa, yes your assumptions are more or less correct in the post after mine (then 3rd player long-term will come into play as well).

@Sergejs, appreciate the feedback and the clarification. Thanks!