I disagree. Whether or not it will break depends on what changes are made to the API, and to some degree dependencies. It can break “at any time” when these things are changed, and given that “major releases” are time-based, not feature-based, there really is no correlation of even probability. I just made an add-on here the other day which I expect to work from 4.1.0 (I haven’t actually tested it on anything older than 4.2.3) and “far into the future”. I could have made it work with even earlier versions, but I would have to have made it for Java 11, while I chose Java 17, which dictates the lower limit. It also works perfectly fine with 5.1.
When it comes to non-bundles, like UI widgets etc., it’s even more unpredictable when or if it will break.
The “common practice” now is to set the upper limit to the next major version, but this has a bade side-effect - things just “disappear” from the marketplace for no good reason when a new major version is released. I observed that lots of stuff “disappeared” with 5.0, because nobody has updated the range. The vast majority most likely works just as well with 5.x.
I think a much better strategy would be to have them open ended, unless a known factor that will break them exists, and that the upper end is modified when they are known to break. This wouldn’t have to rely on the original authors, when it is discovered that an add-on is in fact broken, moderators or others with access could modify the range. I think this would give the best user experience overall, because nobody is in a position to actually predict when they will break.
The factors that decide if something breaks or not are way too complicated to predict, which is why official add-ons are built every night. That way, changes that cause breaks are detected and can be addressed immediately. You can’t expect marketplace add-on authors to have an automated build environment that does the same, which means that there’s no “automated” way to figure out when they break.
It’s indeed silent, and it’s also bugged in that it isn’t thread-safe, so multiple installation attempts are started in parallel, which I assume is the most common reason why they fail. I have already made fixes for many of these things in my previous work.
The JSONDB is automatically cleared of all add-ons that aren’t currently installed:
… but kept in missingAddons, which gets one install attempt further down:
if (!missingAddons.isEmpty()) {
logger.info("Re-installing missing add-ons from remote repository: {}", missingAddons);
scheduler.execute(() -> missingAddons.forEach(this::install));
}
That attempt logs one line that should be visible in the log.
The subsequent installation attempt doesn’t log anything, but instead creates events, which I assume should be visible in the event log: