From Univention Wiki
Univention releases minor and major updates to UCS. These updates follow a maintenance policy; eventually, UCS versions go out of maintenance. Please refer to Maintenance Cycle for UCS to see which UCS version is maintained until when.
As an App Provider, you need to decide which UCS version to support. The Provider Portal supports creating Apps for all UCS versions currently under maintenance (and maybe even an upcoming version).
For Non-Docker Apps, this is straight forward: The packages exist in the repository of the UCS version the App is published for. When a new UCS version is released, you need to add a new App for that UCS version, otherwise users of the App are blocked from UCS updates! Therefore, you should add a new App version as soon as possible.
For Docker Apps/Image Based, it is a bit tricky - but easy. As the App is a container and has little interaction with the host system, it is unnecessary to publish a new version for, say, UCS 4.3, if it has already been published for UCS 4.2. UCS 4.3 systems may very well use the App - if you specified SupportedUCSVersion=4.2-0, 4.3-0 in your 4.2 App. It does not really matter in which UCS version you are publishing your App. But if are publishing it in various UCS versions, you need to also test various UCS versions!
For Docker Apps/Package Based, it is a little bit more complicated (but really only a little). The packages are hosted for the UCS version you published the App for. So if you are using appbox:4.1-4 as the container, you should publish the App in UCS 4.1. The container will be UCS 4.1, so it needs to find its packages in UCS 4.1 repositories. If you are using appbox:4.2-3, you should publish it in UCS 4.2. You can still set SupportedUCSVersion=4.2-0, 4.3-0. The UCS 4.3 system will then run a 4.2 container with 4.2 packages.