Usually, my mods have been noted to be quite eager to update to the latest versions, specifically Alex's Mobs and other newer (post-2020) releases. The reasoning behind this was a combination of multiple factors. One of these was a desire to utilize new features, additions and changes to Minecraft's mechanics, both those that are front-facing (such as new mobs, archeology, etc.) and changes in the back-end, such as increasingly data-driven features such as biomes and paintings becoming entirely JSON-based. Another was a belief that latest versions would also be the most regularly played, and that by a mod being on the latest version, it would make upgrading it to the next iteration of that version far more trivial than staying on one version for a while.
However, this approach had drawbacks. Chiefly among this is that it further enabled a sort of chicken-and-the-egg effect with players updating versions so quickly that it contributed to not a lot of large, in-depth mods being developed for newer versions of Minecraft. It also resulted in my mods typically not being on the version that most players were using. But also - it drew my maintenance focus away from older (but more widely used) versions of my mods that needed bug fixes and features. Yet with all these drawbacks considered, it was still more efficient to port the mod to latest release versions of Minecraft if only to save time repeating the process in the future.
This is no longer the case in the post 1.20 versions of the game. Mojang has changed how versioning works completely for the game - so that internal changes between _._.0 and _._.1 are now more comparable to changes from _.X._ and _.Y._. The reasoning behind this is that it allows more responsible fixing of issues and improvement of back-end functionality that most players don’t interact with or feel the changes of other than smoother gameplay and a lack of lag and crashes; but it definitely does feel like a contribution to the ambient narrowing-out of the Java modding scene, intentional or (probably) not.
Further cementing my position on lingering a bit longer between versions is conflict in the modding sphere entirely outside of Mojang-driven changes. Forge has completely split into the new NeoForge and the old modloader maintained by LexManos. I quite frankly don’t have a dog in the fight here - the drama between these two is honestly very removed from my sphere. Although, since NeoForge has more maintainers and seems to be the wider accepted loader for future versions of the game, it appears that I’ll be developing my projects for NeoForge loader versions in the near future. As it stands now, all of my 1.20.1 projects use the final version of Forge that’s supported by both loaders, so I am still yet to see how picking a camp on this affects my community at large. From what I can see NeoForge seems intent on completely changing the internal infrastructure of the mod loader. Whilst these rewrites may be completely necessary, it still means a heavy load of tinkering to update my mods for seemingly small version bumps, since these internal forge changes will be dealt with in the same breath as those from Mojang.
Overall, what this means for my modern projects it that they’re likely to remain in the current version - 1.20.1 as of the time penning this - for a while, at least until there’s a stable 1.21 versions that isn’t being renovated by Mojang or the NeoForge team every two weeks. Now, this might sound like a bad thing, but if you’ve been in the modded Minecraft community for long enough, there were many eras of punctuated equilibrium just like this, namely 1.4.7, 1.7.10 and 1.12.2 versions, which all sported a great flourishing of modded content. Maybe with some luck, 1.20.1 or 1.21.X could become one of these versions too. We’ll just have to wait and see.