I'm not aware of any "official" guidance from the core team hiding in Discord, so for now these are just my own impressions for people to agree/disagree with and discuss further:

maximum_ap_version is a niche option. It is rare that you know AP is about to break you, care enough to write that down, yet you also can't just fix the breakage immediately. Especially since this is Python and you can do shenanigans like try: import ... except: when symbols get moved around (I'm currently doing this myself with rule builder). The only true use case for maximum_ap_version that I'm currently aware of is Universal Tracker, because they're sufficiently coupled to core's generation that when core breaks UT, there's often no way to update UT such that it just works both before and after the change. Either they wait for the AP change to reach users before a UT update would help, or they maintain two parallel releases of UT for different ranges of AP versions like they did for the kivymd migration.
Most AP players should be on the latest version of AP or close to it. Long-running async games typically justify being one, maaaaaaaybe two releases behind (given AP only has a few releases a year). But e.g. nobody should still be on 0.6.0 or earlier in 2026. The point of bringing this up is: for world devs, it's generally not worth the effort to figure out your "true minimum" AP version.
IMO the most cost-effective way to handle minimum_ap_version is to set it to latest stable when you initially create your .apworld. Then in the future, whenever you hear about a new AP feature you want to use, consider whether it's worth a) bumping your minimum_ap_version, or b) writing code to conditionally support both, or c) the feature is not valuable enough to justify a or b so you don't use it after all. If you aren't actively adopting new AP features, then this minimum_ap_version should just remain correct without any real maintenance effort.

Docs: Best practice for maximum/minimum_ap_version #6002

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions