Fix Versions
POs are responsible for making sure that there is a “fix version” in Jira for each of their components and that the fix version is on the right tickets in that version. This fix version is also added to the deploy task that is assigned to the RM, so they know what stories should be in that release.
Fix Version Naming Convention
If we have multiple stories going out in one release for a sprint, we would name that release “<service>: Release A”. Once the PO cuts a release and creates the deployment ticket for the Release Manager, the fix version name is updated to “<service>: x.x.x”, like eula-web: 1.22.0
If we have a component with stories that will go in more than 1 release, then multiple fix versions are created for Release A, Release B, etc. The correct fix version should be added to the issue for the release it’s in. Example: eula-web: Version A, eula-web: Version B. The version that is added to the deploy ticket for the RM should have the correct version and they (or the PO before it’s given to the RM) will update the fix version name to include the version. Example eula-web: Release A becomes eula-web: 1.22.0.
If the story will not be released during the sprint but the changes will be put on the main branch then we name the fix version “Service: Main”
|
Worked Example
Currently, I’m working on a release that is going from 1.15.1 to 1.18.0. On the Release Board, the following versions exist: 1.16.0, 1.16.1, 1.16.2, 1.17.0, 1.17.1, and 1.18. Before I’m able to complete the V&V report, I have to go merge all of these versions to allow the report to pull all tickets that were completed between versions 1.15.1 and the current version that is going to production. In theory, all of these tickets should have had a release version of "release A" and then I would have only changed one item from release A to 1.18.0 to update all the tickets. |