In this video, we will discuss versions. We will start with the versions overview. A version is a set of issues for a project that are usually considered to be a single product update. The word usually is used here because it is up to the team to decide the purpose of the version. A version is also called a release. Here's a version in project A that we named 0.1. This version contains four issues. Versions in Jira serve a number of purposes. It's up to every team to decide how they want to use them. The sets of issues and versions are a way to organize issues. You can easily find the issues related to any version. If your project has a number of fixed release points, versions in Jira help schedule them. Identifying issues for release and specifying unexpected release date sets a goal for the team. Versions can be used in queries and reports. For example, you could view all of the stories that were completed in a specific version or view a report on the progress of the version that you are working on. Versions can also be used to remove done issues from kanban boards. Kanban boards have a continuous flow of issues, and versions are a way to prevent the done column from continuously growing in size. Scrum does not have this problem because sprint boards have a relatively fixed number of issues and have shorter lives. The primary field related to versions is the fixVersion field. If the fixVersion field of an issue has a value, the issue belongs to a version. Here we are editing an issue. You can see that there's a fixVersion field with a value of none. This issue does not belong to any versions. It is not editable here because no versions have been defined for this project. FixVersion is a bit of a historic name. Jira primarily started out as a bug tracker for software projects. FixVersion originally represented the version of the software where the bug was fixed. There's also an affectsVersion field which typically represented which version the bug was founded. In none bugs situations, you can think of the fixVersion field as the primary version field because it applies generally to all types of Agile issues. Each version has a version status. An unreleased version is a set of issues in preparation for a release. For example, a team could create an unreleased version and assign five issues from the backlog to be part of that version. The released version usually represents a set of issues that have been delivered to the customer. An archived version is an historic set of delivered issues. Jira hides this version from the user interface and release reports. An archived version is a relatively subtle concept in Jira. Issues in all versions are still query-able. As long as you have permission to see the issues, you can search for them. They still belong to a project. There are two general stages of working with a version. The first is to create the version. When you do this, you assign it a name and other optional metadata such as its release date. The version has an unreleased version status. The team can then add issues to the version in preparation for release. When the issues of the version are done, the version can be released. The version status is changed to released or archived. We will first discuss working with versions independently from a board. We'll then see that from a kanban board. You can combine these stages, creating and releasing the version in one step. Next, we will discuss two-stage releases. To begin creating a version, you can click on the Releases tab in the project sidebar. This method of creating a version is independent of boards and can be used for issues in any type of project, including kanban and Scrum projects. When you click on the Release button, you are prompted to enter the version metadata. You must specify a version name. It can be a number such as 0.1 or any other name such as a code name for the release. Optionally, you can enter a start date, release date, and description. When you specify the release date that is in the future, it is a goal, and Jira will inform you by displaying the version named in red if your release is overdue. Another way to create a version for Scrum projects is from the Versions tab of the Product Backlog using the create version link. For kanban projects, if you have the kanban backlog enabled for your board, you can create a version from the backlog. Just like with Scrum projects, there's a Versions tab containing a create version link. Here's the Releases tab after we create aversion. Notice that when you create a version, it has an unreleased status. Also notice that it contains no issues. The version is ready to have issues added to it. To add an issue to a version, open the issue and click on its fixVersions field. You can then select the version or versions that you want to add the issue to. You usually makes sense to add it to a single unreleased version, but you could also add it to a released version. You can use the Releases tab in the project sidebar to view details of the release at anytime. Here's our unreleased version containing one done issue. If you create a version and have a number of existing issues that you would like to add to it at once, you can both change the issues. Here we have performed a basic search, where we search for issues from our project that are either in the selected for development or in-progress statuses and do not have the fixVersion field set. Assuming that these are the issues that we would like to add to the release, we can click on the More menu in the upper right and select Bulk change alt issues. After selecting the issues that you want to add to a version, you can select Edit issues to begin the process of adding a fixVersion value to the issues. You then check the change fixVersions box and can add the unreleased version as a value for the field. For Scrum projects, you can add completed issues from a sprint to a version. Here we have done a basic search for issues from a completed sprint with a status of done. We can then bulk add these issues to our version. We can view our version under the Releases tab in the project sidebar and see that the issues have been added to the version in bulk. We can see the current progress of the version, including workflow status of each of the issues. You can click on the View in Issue Navigator link to view the list of issues as a query result. Here's a list of issues from the version in the issue Navigator. You can see the query that is used to show these issues. The query is scoped to a project because projects may use the same version naming scheme. The fixVersion field is used to find issues from version 0.1. If you view the details of an issue in a version, you will see that the version name is assigned to the fixVersion field. You can click on the version name to switch to the issue navigator, showing the issues of version. As you are working on a version, you can view version related reports, such as the version report shown here. This applies mainly to Scrum projects. This shows you your story point progress to see if you are on track to release the version on time. To release a version, you click the release button. If you click the Release button when some of the issues are not done, Jira will warn you and ask you if you really want to do this. You can release a version in this state but usually you want all of the issues to be done before releasing them. When the issues of the release are done, you can click the release button, specify the release date, and click the release button to change the version status to released. On the releases page, there's also a more icon to the right of each release containing actions related to the releases. Unreleased will change the release status to unreleased. In our case, the issues will appear again in the done column of the Kanban board but the issues we'll still have a fixVersion of 0.1. Archive will change the version status to archived. The version will appear in less of the release related user interface elements and reports. Edit allows you to change the metadata related to the version. Delete removes the version. You must choose what happens to the issues of the version. You can either move the issues to a different version or simply clear the fixVersion value for the issues. This does not delete any issues. If you have multiple versions, you also have the merge option for releases. You select the merge option for the release that you want to merge into another version. Here we will select Merge 0.1 version. You then select which version to merge into. All of the fixVersion values will be changed to this version and version 0.1 will no longer be available. Next, we will discuss kanban board releases. Another fundamental way to create a release is from a kanban board. A kanban board contains a continuous flow of issues. There are always issues moving to the Done status. Anytime that there are issues in the Done column, the "release" dropdown in the upper right is enabled. If you are ready to release you can create a version that contains the Done issues by selecting the new version option from the "release" dropdown. This allows you to create the version and release it at the same time. In this example, if we create the release now it will contain these four issues from the Done column. When creating the release, you specify the version metadata like you did previously. The release date will automatically be filled out for you because you are creating and releasing the version in one step. For this same reason, there is no start date on this form. Clicking release will create the release with the released status and containing the 4 issues. Notice that after their release, the Done column has been cleared and the "release" dropdown is not enabled because there are no issues in the Done column to release. Next we will look at what happened to the issues that were in the Done column. We have seen that boards have filters which define the issues that appear on the board. If you scroll to the bottom of the General tab for the board settings you will see that there is also a sub filter, this is an additional filter that limits the issues displayed on the board. The sub filter is what makes the issues and the Done column disappear from the board when you release a version. The sub filter is allowing any issue with an empty fixed version field to remain on the board as well as any issues that belong to a version that has not been released. The query is using the unreleased versions JQL function to determine the version status. Any issues with the fixed version value of aversion that has a version status of released or archived will not appear on the bullet. If you also wanted to view all done issues on the board you could create another board and remove this subfilter. Here are the version related JQL functions. You can find these in the advanced searching functions reference. There are two functions related to unreleased versions. The first is the unreleasedVersions function, the project argument is optional. If you don't pass a project name, the function applies to issues of all projects of the Jira column. As an example, this query searches for all issues in the project A project that are in any unreleasedVersions. We just saw that this function is used in a some filter for the project board so that issues that are part of an unreleasedVersion still appear on the board. The earliest unreleasedVersion function searches for issues in the oldest unreleasedVersion. This is probably the next version to be released. The two functions related to the ReleasedVersions are basically the opposite of the unreleased functions. The ReleasedVersions function helps search for all issues that have been released, the latestReleasedVersion function searches for issues that were in the most recent release. You can use the releases tab in the project sidebar to view the version that you just released. Makes sure that the version status filter is set to all statuses and your release will appear containing the metadata that you specified when creating the version. Notice that the status is released. Here's a review of what we've discussed in this video. A version is a set of issues from a project that are usually considered to be a single product update. If the fixVersion field of an issue has a value, the issue belongs to a version. Versions have a version status unreleased, released or archived. Add multiple issues to a version by bulk changing the fixVersion field. The "release" dropdown on a kanban board allows you to create and release a version that includes all done issues on the board. The default kanban board subfilter removes done issues if they are part of a released version. Now it's time for you to work on some of the things discussed in this video, separate hands-on instructions are provided for you.
