Multi variant releases
Vampire opened this issue · 2 comments
If you want to use newer things in newer TeamCity version that are incompatible with older TeamCity versions but still stay compatible with the old version, you need to release multiple versions with different min- / max-builds.
For example currently if you set the allow-runtime-reload and try to deploy your plugin to 2018.1, the validation of the plugin descriptor fails. For 2018.1.4 Jetbrains will probably backport compatibility for that, but if you e. g. want to be compatible with older versions, or with other breaking changes in the future, you need to release multiple variants.
Would be nice if this were somehow nicely supported by this plugin, e. g. by having multiple source sets for different versions and then building multiple distributions and release them all or something similar.
I didin't think the min/max-builds properties were used by TeamCity, I could be wrong.
To support multiple versions you can do this with sub-projects and the teamcity-server plugin. For example you can have a sub-project that builds a shared server-side library, but does not define a TeamCity descriptor, this means the serverPlugin task is skipped. Then for each TeamCity version you want to build for have a sub-project that depends on the shared server-side library but does define a TeamCity descriptor and sets the API version.
The JetBrains Azure plugin used the above approach, look in the plugin-azure-server-base/arm/asm sub-projects.
At least the plugin portal should evaluate it. There you see a compatibility field and the Jetbrains guys advised to release current variants for different incompatible versions.
Yeah, with subprojects it can be done of course, I just thought some nice support by the plugin would be handy, especially when you finally support agent and server in one project by using source sets.