Would selectivly need to publish a few BOMs for older lines so that the plugin-pom would still work (which would get funky as far as permissions in repository are perhaps concerned...)
>There is no way it gets backported to LTS, so I removed the label
yes there is, I can adapt it and it can be included. the label is to start a discussion. I do not think the libraries have changed here so it can also be a simple cherry-pick.
Granted you could call this a feature that is not eligible, but you could call it a bug that the correct libraries are not used in a plugin build based on the Jenkins version.
>There is no way it gets backported to LTS, so I removed the label
yes there is, I can adapt it and it can be included. the label is to start a discussion. I do not think the libraries have changed here so it can also be a simple cherry-pick.
Granted you could call this a feature that is not eligible, but you could call it a bug that the correct libraries are not used in a plugin build based on the Jenkins version.
There have also been some special cases historically.
Note that the 2.190.1 RC has testing has already started. Even if there is a consensus to backport it, it is likely to be 2.190.2 only
My suggestion would be to actually consider doing this:
> Would selectivly need to publish a few BOMs for older lines so that the plugin-pom would still work (which would get funky as far as permissions in repository are perhaps concerned...)
It is funky indeed, but it is technically doable. My suggestion would be to deploy BOMs for 2.138.3 and above so that we can start consuming it in plugins quickly. Deploying it for last baseline releases (2.138.3, 2.150.3, 2.164.3, 2.176.3/4) would be enough imho
> Even if there is a consensus to backport it, it is likely to be 2.190.2 only
If it prevents the "oh shit I forgot to push a release of the bom after a release was made" that's a win in my eyes. We're aware the .1 boat has sailed and we where a little late to merge the original bom and hence make the backport request.