I suppose we’ll need to be mainly careful after branching. For everything we’ll cherrypick to the stable branch, we’ll need to modify fixed in version. How does it deal with something, that already has some version set?
Thanks @ekohl, looking forward to see this in action.
My initial thought was to derive the version from the branch name (1.22-stable → find the next open 1.22.z) but first we want to focus on the main workflow which will save the most time.
I wouldn’t mind automating this at a later stage but there’s a difference between Katello and Foreman workflows. Katello saves up all cherry picks and does a bulk PR before release where Foreman picks all the time and then does a release. Because of these differences @tbrisker convinced me to split the effort and first release this.
It’s written to be careful. So it first retrieves the versions. If the intended version is missing, it’s added. I’m sure there’s a race condition between the retrieval and storing, but I think it’s unlikely we’ll hit this.
I would love to see theese processes formalized and maintained somewhere. I do not have enough experience how to do so for being really helpful, but some graphviz, or even just an draw.io process chart would be nice to have.
Anyway, I love automating that I feel this really necessary as some maintainers easily forget (for example @ezr-ondrej is really slopy one! )
Great feature, thanks @ekohl!
Does being installed for theforeman mean it will work on all repos in th org?
What are the prereqs for the script to work? Is existing correct and open version in Redmine enough?
For Hammer project in Redmine we use different versions for hammer-cli and hammer-cli-foreman. Could it be possible to set mapping between github repo and the specific version set?
It only works on projects which have a Redmine project set in the config. For example, Hammer is configured this way:
However, I now see that hammer-cli-foreman uses the same project but prefixes the version: (Roadmap - Hammer CLI - Foreman). This is where my script would currently likely fail. LooseVersion('hammer-cli-0.18.0') < LooseVersion('hammer-cli-foreman-0.18.0') raises a TypeError.
I can see a redmine_version_prefix setting where we strip away the prefix. Then see if it starts with a number. Only then do we consider it a valid version to compare. I think then this would work for the Hammer usecase.
Thanks for making me look at other use cases that would have broken otherwise
Going over the projects I see two cases that are not standard:
Discovery uses Discovery Plugin Next which would not be recognized. Easiest workaround would be if it was renamed to Discovery Plugin 1.NEXT or used an explicit 1.16.0 for the next minor like others do. @lzap?
Remote execution has foreman_remote_execution x.y.z and foreman_remote_execution_core x.y.z. I wouldn’t know which to pick. I can either configure it to one of the two or a non-existing prefix to disable it. @inecas / @aruzicka?
The alternative was to create Redmine sub-projects but that might be a lot of work and only confuse end users who want to create a bug report.
I’ve added a commit, but for now it’s untested. Unless there are objections I’ll roll this out tomorrow and monitor the logs for issues. A message will be posted here when it’s live. Then I’d ask maintainers to watch for any incorrect Fixed-in-release values.
Of course I can change that, the idea behind this was that I am very strict about semantic versioning (or at least I try to), so I actually don’t know if the next discovery is gonna be 16.0 or 15.1 because this depends on core changes. So I guess I will simply set 15.1.0 for now and if it turns out to be 16.0 just renaming should do it and no further action is needed because 16 > 15.1. Not sure if this would cause any pains for rel-eng process tho, in that case I’d need to mass reassign fixed in version 15.1 issues to 16.0. Can do manually, not a big deal.
I changed it. Hope that Discovery Image and Discovery Plugin version scheme is not causing you any issues. In the worst case we could create new project for FDI.
Looks like there isn’t support for fixed in version from the bulk edit, which kind of makes sense since issues can have multiple fixed in version. I think renaming a version oth should be pretty easy from the project settings page.
In this cases, I would recommend to primary use the foreman_remote_execution - even when core gets update, it usually is released with new foreman_remote_execution and provided (I assume), it can be changed manually later, it’s good enough solution IMO
I feel this really necessary as some maintainers easily forget (for example 
)
