Skip to end of banner
Go to start of banner

DRAFT: Jira Fix Versions Management Guideline

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

This Guideline is being drafted at the moment.

Please, refrain from adding comments and questions until the draft is complete and presented for review and discussion on Tech Leads meeting.


ActionExampleAssumptions
1

Create Versions in Jira:

  1. Navigate to your Jira project and
    1. go to Project Administration OR
    2. go to Manage Versions on Releases page
  2. In the Project Administration menu click on Versions

  3. Fill in Version name, Version Description and Start date, and click Add

  4. Use Drag&Drop to rearrange order of Versions in the list

 OR 

  • Scrum Master is accountable for creation of required Versions in Jira projects corresponding to the modules and other FOLIO software components (plugins, libraries, etc.) owned by their team (see Team vs module responsibility matrix).
  • Dev Lead can be responsible for creation of required Versions in a team's Jira projects if agreed within a team, but Scrum Master remains accountable for making sure required Versions are created in Jira projects.
2

Make sure three required Versions are created for each Jira project corresponding to the modules and other FOLIO software components (plugins, libraries, etc.) owned by a team and meaningful Version Descriptions are added:

  1. Bugfix/Hotfix Release version (x.y.Z) with Z incremented
  2. Minor Release version (x.Y.z) with Y incremented
  3. Major Release version (X.y.z) with X incremented

  • Three required Versions should be created for every Jira project, so that an appropriate Version can be selected by any developer based on the nature of their task. Most developers do not have permissions to add Versions to Jira projects, thus three required Versions should be created in advance to be available for developers when needed. 
  • There can be exceptional cases with more than three unreleased Versions available because of requirements to create additional Hotfix releases for some previously delivered quarterly releases. 
3

Update Fix Version field in a Story/Task/Bug selecting an appropriate Version after code changes have been merged:

  1. On View Issue screen update Fix Version field by selecting an appropriate Version from unreleased versions available in the dropdown;
  2. OR from Backlog view select a story/task/bag and use Drag&Drop to associate it with a proper Version in Versions left side bar;
  3. OR from Edit Issue screen update Fix Version field by selecting an appropriate Version from unreleased versions available in the dropdown

There should be at least three unreleased Versions available: 

  • Bugfix/Hotfix Release version (x.y.Z)
  • Minor Release version (x.Y.z) 
  • Major Release version (X.y.z) 


OR  OR


Bugfix/Hotfix Release version (x.y.Z)

  • if only backwards compatible bug fixes are introduced to fix incorrect behavior
  • if changes that do not affect the interface, have no changes in API, have no any new functionality added

Minor Release version Y (x.Y.z)

  • if new, backwards compatible functionality is introduced
  • if any public API functionality is marked as deprecated

Major Release version X (X.y.z)

  • if any backwards incompatible changes are introduced

For more details on Versioning see:

  • Developer is accountable for updating Fix Version field and selecting an appropriate Version based on the nature of implemented changes after code changes have been merged.
  • Scrum Master is responsible for reviewing closed issues on regular basis (after every sprint closure) to make sure Fix Versions are not missed.
  • Fix Version should not be specified for any stories/tasks having no code changes merged. For example, spikes, investigations, POCs, tasks closed with resolution Won't Do/Duplicate/Cannot Reproduce and other tasks having no code changes impacting production release artifacts. 
4

3 weeks prior established module release deadline 

Update Fix Version field in an incomplete Story/Task/Bug being not yet merged, if it is confirmed to be a release must-have item.  

When Fix Version added to incomplete must-have items:

  1. Incomplete release must-have items will be added to the scope of corresponding releases on Releases page of a Project
  2. Details on the incomplete release must-have items and their current statuses can be viewed on Version details page and used for understanding of module readiness for release


Note: If incomplete item is not assigned to an appropriate Version in Jira in time, there is a great chance it won't get into Release as the team owning a module can start Release procedure earlier than the item is completed.  


  

  • Product Owner is accountable for reviewing Release progress and identifying incomplete release must-have items 3 weeks prior established module release deadline.
  • Developer is accountable for updating Fix Version field and selecting an appropriate Version based on the nature of code changes planned to be implemented for the items confirmed to be release must-haves.
  • Scrum Master is responsible to make sure release progress review is done by a team and Fix versions are added for incomplete release must-have items.
  • Release Coordinator is responsible to add this action to Release timeline.
5

2 weeks prior established module release deadline

I. Confirm the Version to be released and Delete unnecessary Versions:

1. if there are items in Bugfix release version only or if a Bugfix/Hotfix Release is required: 

→ Bugfix release version is planned for release

→ No need to remove any Versions

2. if there are items in Minor Release (and Bugfix) version AND no items in Major Release version:

→ Minor Version is planned for release

→ Bugfix Release version must be deleted; while deleting - all issues assigned to Bugfix release version must be moved to Minor Release Version planned for release to be included into corresponding Release notes

3. if there are items in Major Release (and Minor/Bugfix) version: 

→ Major Version is planned for release

→ Bugfix and Minor Release versions must be deleted, while deleting - all issues assigned to Bugfix/Minor release versions must be moved to Major Version planned for release to be included into corresponding Release notes

II. Proceed with Release Procedure for a module as soon as all the items assigned to a Version planned for Release are completed:

1. if all items assigned to a Version are closed

→ Proceed with Release Procedures

2. if 1 week before release deadline there are still some incomplete items

→ Double-check with corresponding PO/team if they are on track to get it completed for the planned Release or it should be deferred to the next one and, thus, removed from a Version currently planned for release. 


  • 2 weeks prior established release deadline all the complete and incomplete issues planned for next release must be already assigned to corresponding Versions in Jira by all development teams involved, thus it must be possible to confirm at this point which Version is going to be released.
  • Deleting unnecessary Bugfix/Minor Versions is required if they are not going to be released, so that all issues completed and assigned to Bugfix/Minor Versions are moved to a Version planned for release and are included into its Release Notes in Jira.
  • Scrum Master is accountable for deletion of unnecessary Versions in Jira and moving issues to a Version planned for release 
  • Dev Lead can be responsible for deletion of unnecessary Versions in Jira and moving issues to a Version planned for release, if agreed within a team, but Scrum Master remains accountable for making sure the Version to be released is confirmed and unnecessary Versions are deleted.
  • Release Coordinator is responsible for monitoring release readiness status and sharing the updates via Slack channel and while Release Weekly Status Review meetings. (the report can be fetched based on incomplete items assigned to Version planned for release + blockers/dependencies linked to release stories)
  • No labels