JIRA is now available as three separate applications, JIRA Software, JIRA Service Desk, and JIRA Core. For more information on administering these applications, refer to the Administering JIRA Applications documentation.

Managing Versions

Versions are points-in-time for a project. They help you schedule and organize your releases. Once a version is created, and issues are assigned to it, a Releases link will be available in your project navigation sidebar.

Versions can be:

  • Added — create a new version against which issues can be aligned.
  • Released — mark a version as released. If you have integrated JIRA with Bamboo, you can also trigger builds when releasing a version.
  • Rescheduled — re-arrange the order of versions.
  • Archived — hide an old version from the Releases report, and in the JIRA User Interface.
  • Merged — combine multiple versions into one.

On this page:

Managing a project's versions

  1. Log in to JIRA as a project administrator.
  2. Choose > Projects, and click the name of a project. The Project Summary page is displayed (see Defining a Project).
    (tick) Keyboard shortcut: g + g + start typing project
  3. Choose Versions in the left sidebar. The Versions page is displayed, showing a list of versions.

    Screenshot: The 'Versions' screen

Add a new version

  1. The Add Version form is located at the top of the 'Versions' screen.
  2. Enter the name for the version. The name can be:
    • simple numeric, e.g. "2.1", or
    • complicated numeric, e.g. "2.1.3", or
    • a word, such as the project's internal code-name, e.g. "Memphis".
  3. Optional details such as the version description (text not HTML), start date and release date (i.e. the planned release date for a version) can be also be specified.
  4. Click the Add button. You can drag the new version to a different position by hovering over the 'drag' icon at the left of the version name.

Add a start date

If specified, the Start Date is used by the Version Report. This gives you a more accurate report in cases where you might plan a version many weeks (or even months) in advance, but not actually commence work until closer to the release date.

Release a version

(info) Before you begin: If you have integrated JIRA with Atlassian's Bamboo, you can trigger a Bamboo build to run automatically when releasing a version in JIRA. The version will only be released if the build is successful. See these alternate instructions: Running a Bamboo Build when Releasing a Version.

  1. On the 'Versions' screen, hover over the relevant version to display the cog icon, then select Release from the drop-down menu.
  2. If there are any issues set with this version as their 'Fix For' version, JIRA allows you to choose to change the 'Fix For' version if you wish. Otherwise, the operation will complete without modifying these issues.

(info) To revert the release of a version, simply select Unrelease from the drop-down menu.

Archive a version

  1. On the 'Versions' screen, hover over the relevant version to display the cog icon, then select Archive from the drop-down menu.
  2. The version list indicates the version 'archived' status with a semi-transparent icon. The list of available operations is replaced with the 'Unarchive' operation. No further changes can be made to this version unless it is un-archived. Also it is not possible to remove any existing archived versions from an issue's affected and fix version fields or add any new archived versions.

(info) To revert the archive of a version, simply select Unarchive from the drop-down menu.

Merge multiple versions

Merging multiple versions allows you to move the issues from one or more versions to another version.

  1. On the 'Versions' screen, click the Merge link at the top right of the screen.
  2. The 'Merge Versions' popup will be displayed. On this page are two select lists — both listing all un-archived versions.
    In the 'Merging From Versions' select list, choose the version(s) whose issues you wish to move. Versions selected on this list will be removed from the system. All issues associated with these versions will be updated to reflect the new version selected in the 'Merge To Version' select list. It is only possible to select one version to merge to.
  3. Click the Merge button. If you are shown a confirmation page, click Merge again to complete the operation.

Edit a version's details

  1. On the 'Versions' screen, hover over the relevant version to display the pencil icon.
  2. This will allow you to edit the version's Name, Description and Release Date.
  3. Click the Update button to save your changes.

Delete a version

  1. On the 'Versions' screen, hover over the relevant version to display the cog icon, then select Delete from the drop-down menu.
  2. This will bring you to the 'Delete Version: <Version>' confirmation page. From here, you can specify the actions to be taken for issues associated with the version to be deleted. You can either associate these issues with another version, or simply remove references to the version to be deleted.

Reschedule a version

Recheduling a version changes its place in the order of versions.

  • On the 'Versions' screen, click the icon for the relevant version, and drag it to its new position in the version order.

See also

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

49 Archived comments

  1. User avatar

    Alec West

    Is there any non-GUI way to release a Version?  Is there an option to have a Version auto-release on the releaseDate?


    13 Apr 2012
    1. User avatar

      Chris Patti

      I've been wondering about this too.  The dialog that comes up when you click "Release" takes several minutes and (I can only view this as a bug) pretty much locks up my browser while I wait).

      I was hoping to do this with the JIRA CLI, but it doesn't seem possible.  I'm struggling to understand the REST API to see if it's doable there.

      23 Jul 2012
  2. User avatar


    I have created versions for a project, but in the "Create Issue" form, there is only option to select "Affects Version". The "Fix Version" is not appearing. How do I add this? Agile view is not useful without it!

    Thank you!

    23 Apr 2012
    1. User avatar

      Guy Lepage

      +1 I would like to know how to edit "Affects Version" as well.

      26 Nov 2012
  3. User avatar


    Is there a possibility to manage versions without the "administer-projects" permission?

    Can I give that specific permission to some users who are not project-administrators?


    25 Apr 2012
    1. User avatar


      I wish this existed too. We have some people we just want to be able to manage versions & components for one specific project. 

      07 May 2012
      1. User avatar


        And I clearly should read better, just figured that you only put it on the project(s) you want the users to administer...duh.

        07 May 2012
  4. User avatar


    How about the ability to add the start date to the version so that the classic burndowns work properly, otherwise they start at todays date, not particularly useful!

    11 Oct 2012
    1. User avatar


      ability to add a start date to versions would be very useful for us.

      24 Oct 2012
      1. User avatar


        Any update on this? We would really need a version start date! Still not possible?

        22 Jan 2013
  5. User avatar

    josh kerbel

    I am in the midst of creating/dividing my application in to different versions.   My question relates to the assignment of an issue to more than one version.  Rather than talk in the abstract, I will try to outline this in a Use Case

    Use Case.

    Issue A (and its sub issues) relates to version 1 and version 2 of my software, so I tag Issue a with both version tags (1 and 2)  in the version dialog.

    Now when I go to close Issue A as it relates to version 1 (we did the Issue A sub tasks associated with version 1), how does this impact the relationship between Issue A and version 2, does Issue A remain open when viewing Version 2, or is it automatically closed in version 2  as a result of closing it in version 1?   In other words, am I required to break down Issue A into two discreet issues, one for version 1 and one for version 2.  My initial assumption is that I don't, otherwise why would I be able to assign an issue to more than one version



    25 Oct 2012
  6. User avatar

    Hugues Lecerf


    is there a way to automatically archive all the version numbers that doesn't have any open bugs remaining in the database ?

    Thanks for your help

    04 Dec 2012
  7. User avatar

    Paul C George

    As of JIRA 5.2.1, Versions don't work that way at all. There is a '...add X more' link, the result is not a table, and there appear to be no mechanisms for adding Versions.t

    17 Dec 2012
    1. User avatar

      Andrew Lui [Atlassian Technical Writer]

      Hi Paul,

      I just tried viewing the Versions administration screens in JIRA 5.2.1 and it matches the documentation above. Can I ask you to log a request with our support team at https://support.atlassian.com for assistance?

      Kind Regards,

      17 Dec 2012
      1. User avatar


        tilyingomelegeMy bad. From the Project Summary page it doesn't work as described. From Project Configuration it does

        17 Dec 2012
  8. User avatar

    Bob Burcham

    We recently migrated to GreenHopper 6.1 and JIRA 5.2.  We are now using Sprints and the new Task Boards for managing our work.  Previously we used fixVersion to track our Sprint numbers.  Frequently we are finding the need to access 'older' stories that were completed in our prior version of Jira.  Is there an easier way than using the 'Classic' view to take a look backwards?  Everytime we go to the 'Classic' view, we get the "no longer supporting changes" message which makes some of our folks believe this entire 'Classic' view process will be going away soon.  Thanks!

    16 Jan 2013
  9. User avatar

    Pavel Bulanov

    Is there any way to have a workaround to allow creation of versions not only for Project Administrators?

    We use versions as build number to indicate which build (version) issues is resolved for. Normally at least build integrator needs to create new version in Jira, and it might be even any developer could do that. Same time, I don't want them to be able to add / remove people from the project, which permission is also granted with project administration right. Is there a way to overcome this?

    PS. I first posted this comment to JIRA 5.2 page as it seems to be last released version, but here it's more "living" page.

    29 Jan 2013
    1. User avatar

      Paul C George

      You can create a group and use it in a Permissions scheme to grant Project Administration rights. Since you need JIRA admin rights to do things with groups and schemes I do not beleive this gives them the ability to affect project members.
      (Atlassian Answers would be a better forum for this kind of question)

      29 Jan 2013
  10. User avatar


    I cant see the add\manage versions on a specific project. Is this due to the permissions assigned.. If yes, how do i grant permission to the specific project in which i want to add\manage versions.

    30 Jan 2013
    1. User avatar

      Paul C George

      Short answer, yes. by default the Project Lead has the 'administer project' privilege. To adjust this you need to be part of the jira-administrators group. Check what permission scheme the project is using. Then an administrator can grant you the privilege you need or add you to the group that has it. I would recommend not changing the default schemes. make a copy and change them as needed .

      30 Jan 2013
  11. User avatar


    How to Create a single version and assign it two different projects in JIRA.

    Lets say I have ProjA, ProjB and ProjC and all these projects have issue related to one version i.e ver1. So instead of visiting and creating version for each project, is there a way to create and assign versions to Projects from an admin level ?

    This will be really helpful as the way we are handling projects in JIRA is that one version affects many projects in JIRA.

    03 Apr 2013
  12. User avatar


    If version is archived, can it still be used via API?

    For example, we have a sync tool with other tracking system, run by our customer. Let's say a version is archived and hidden from JIRA GUI. Will this version be still available for a synchronization tool to create an issue via API and assign it to that version?

    20 May 2013
  13. User avatar


    My JIRA 6.0.4 version release dates are different from the Manage Versions page to the Version page.  My Version page states that the Release Date is 24/Sep/2013 and the Manage version page states that the Release Date is 25/Sep/2013.  How can I get the Version page to have the same release date as the Manage Version page?

    26 Sep 2013
  14. User avatar

    Jens Kuttig

    If you want to enable managing versions for the project lead, in JIRA 5.2.5 it does not seem to be enough to grant the project permission "Administer Project" to the project lead:

    The following configuration is set:

    • User Alice is in Group "jira-users". Alice is not in Group "jira-administrators".
    • There is one Permission Scheme "Default Permission Scheme". In this permission scheme the Project Permission "Administrate Projects" is given to group "jira-administrators", Project Lead and Project Role "Administrators".
    • In the Project PROJ Alice is set as project lead. No other role assignements are made in the project.
    • Default Permission Scheme is selected for PROJ.

    Expectation: As Alice is the project lead and project lead has the permission Administer Project she should be able to manage versions.

    Actual situation: Alice does not see the button on the Versions-screen nor does she see the "Administer Project" button on the overview screen of the project.

    Quick solution: When I give alice the role "Administrators" in the project, she sees the buttons and can manage versions.

    18 Oct 2013
    1. User avatar

      Niek Neuij

      Have you found a solution for this? I'm looking for this too, it's weird that team members can't add a new version, but have to walk to an admin instead.

      13 Apr 2015
  15. User avatar


    Can I sort by the Version's due date?

    • project p1 is numbered like 1.11 with the minor version updated regularly
    • project p2 is numbered like 22.0 with the major version updated regularly

    p2 v22.0 is due before p1 v1.11, so I want tasks for p2 v22.0 to appear before p1 v1.11

    Sometimes I can sort DESC on fixVersion which will put 22.0 above 1.11 - but if tasks exist for 22.1 or 1.12, it doesn't help

    08 Nov 2013
  16. User avatar

    Bernd Schneider

    Ist there any reason that there is no possibility to sort/filter the list of versions? The only way would be to manually (drag&drop) sort it which is awful. I would also have expected to have the possibility for a bulk update. Especially for archiving old versions one would expect to have the possibility to select versions "older than X" and archive them in a bulk change.

    Background: We migrated our issues from another system to JIRA and are now facing hundreds of versions which appear rather unsorted in the list.

    26 Nov 2013
  17. User avatar


    Hello! I am trying a migration from JIRA 4.X to a newer version (5.X or 6.X). On the actual version I have integrated confluence 3.X. My question is: Would my confluence version be compatible with the newer version of JIRA? I mean, I don't want to improve my confluence too... Thank you!

    12 Dec 2013
  18. User avatar

    Rakesh yadav

    How to move Test cases from version 1 to version 2 with in the same project


    26 Mar 2014
  19. User avatar

    Avi Ziv

    I would like to know how can i manged same bug in a different versions seperatly.

    For Example:

    I find a bug on version A and start working on it , meanwhile i would like to deal with it in more versions B,C,D. but not in the same BUG becuose there are different gropus that supposed to handle with it.

    23 Apr 2014
    1. User avatar

      Mario Hyland

      The simplest way is to create subtasks for the bug for the fix to each version. An alternative is to clone additional bugs and link them if you wish. I usually design the change management system to separate the bug report from the bug fixes.

      23 Apr 2014
      1. User avatar

        Mario Hyland

        BTW, this is Paul George, not Mario, we use a corporate Atlassian account

        23 Apr 2014
      1. User avatar

        Alex Lewis

        Just to confirm my understanding (when using sub-tasks)... When a bug is raised it will tend to have an affectsVesion, say C to use Avi Ziv's example. The bug goes through a triage process and sub-tasks are created for the versions the bug should be fixed in E.g. A, C and D (even though the bug also exists in B). Those individual sub-tasks are worked on, closed/resolved as they are fixed and the parent bug eventually closed when all the sub-tasks are complete. 

        Would I be right in saying the consequences of this approach are:

        • As the fixes are subtasks the scheduling in JIRA Agile means the parent issue will be scheduled, not the subtasks. The sub-tasks can be assigned and fixed in the various versions in that Sprint. If all the subtasks are not completed (you may not want to tackle the fixes in A and C, just D this Sprint) the parent will remain open and put back into the backlog. If the A fix is not going to be tackled for possibly a long time the parent and A subtask will remain open and in the backlog.
        • Leaving the parent open when the Sprint is closed even though the current Sprint has fixed a sub-task, will mean that the sub-task is still tracked and included in the Sprint Report calculations but the report will indicate the parent wasn't completed that sprint. I think that's the case but if possible it would be nice to have it confirmed, I'm not quite in the position to test it myself.
        • The parent task will tend not to have a fixVersion assigned as the sub-tasks indicate which versions receive(d) a fix.
        • It is probably useful that the triage process updates the affectsVersion of the parent to indicate the versions the bug affects. 
        • If a decision is made to not actually fix the bug in a particular version, a subtask could be created for that specific version and immediately marked as "won't fix" with a comment to identify the reasoning behind the decision. In the case where there was an intention to apply a fix and a sub-task created but it never actually received that fix, the sub-task can also be closed with a "won't fix", again stating the reasoning behind the decision.


        Are there any other consequences to be aware of when using this approach? Any consequences when Searching for issues, JQL, etc?

        Many Thanks,


        25 Apr 2014
        1. User avatar

          Mario Hyland

          Actually both the Parent issue and the subtasks would be scheduled in the Sprint, given you planned to perform a fix in that Sprint. As long as any subtasks remain uncompleted the set of issues would be passed from sprint to sprint as with any other incomplete issue. Completed subtasks are not passed on, just as with any other completed issue. When all subtasks are complete the parent 'problem report' would be closed. Effectively the parent issue is treated much like an Epic.

          For querying and reporting purposes you may choose to use the fix_version field such that the parent issue will have fix versions for all the subtasks, though you might not update it until the related subtask gets closed or at least goes into some QA type state. If you are going to defer a fix for a long time it might be best to not create the respective subtask until you get ready to do it. I would document the decision in a comment or the description.

          Triage could update the Affects version field. If you are not going to patch a version then I would not create a subtask. I would document that eight in the parent description or in a comment. However your approach is not in any way wrong.

          Note that this has some workflow definition considerations. A problem report/Bug should probably have a simple Open => InProgress => Closed lifecycle while a 'rework' subtask type might have steps for formal verification and deployment, particularly if they are handled by different roles.

          • Paul George


          25 Apr 2014
          1. User avatar

            Alex Lewis

            Thank you Paul for your detailed response, very much appreciated. 



            25 Apr 2014
  20. User avatar

    Ankit Kothari

    Is it possible to configure the default fields of versions? I am interested in adding 4-5 custom fields at version level and remove the one we do not need to manage our work. For example: Status of a version. Please let me know if there are any alternatives.



    14 May 2014
  21. User avatar

    Lorenzo Hidalgo

    I am trying to delete versions in JIRA Agile On Demand. I've tried hovering over the version screen, but cannot find how to delete. Help?

    12 Jul 2014
    1. User avatar

      Warren Thompson

      Hi Lorenzo,

      If you are on the Version screen, you need to click on the "Manage Version" button top right. This will bring you into the Versions screen where you should see a cog to the far right when you hover over a version which gives you further options like delete.

      Hope this helps,


      13 Jul 2014
  22. User avatar

    Lorenzo Hidalgo

    Hi Warren,

    Ahhh, I was trying to delete the version in the JIRA Agile Board view. I realized that I had to go to Project > Administration > Version.

    A suggestion for future releases, make it easy to create, rename, or delete within the Agile Board view. If you can create a version from there, you should be able to delete the version - intuitively.




    14 Jul 2014
  23. User avatar

    Avi Afik


    Is it possible to set up a default version such that when a user opens a ticket the 'default version' would appear automatically? If the user would want to change the version then they would have to do that manually.


    24 Jul 2014
  24. User avatar

    Gabi Pavel

    "On the 'Versions' screen, hover over the relevant version to display the cog icon, then select Release from the drop-down menu."


    Correct should be: On the 'Manage Versions' screen


    03 Dec 2014
  25. User avatar

    Thierry Dalon

    I was looking for how to change the status of a version for example to Released. It seems not to be clearly documented.

    04 Dec 2014
  26. User avatar

    Karie Kelly

    If you have an end date for the version, when you select the Release version option, why does the end date change to the day before? 

    07 Jan 2015
    1. User avatar

      Jeff Ripley

      I experience this as well, where the date that comes up when clicking "Release" for a given version is always one day before the provided release date.

      Not exactly a deal-breaker, but pretty annoying when going through many projects with short release cycles.

      30 Mar 2015
  27. User avatar

    Igor Kosoy

    Is it possible to add new custom Date fields to the "Version"? I want to track more than just start and end date?  Thanks!

    27 Jan 2015
  28. User avatar

    Steve Behnke [BlackPearl PDM]

    There's a broken image on this page, at the top. Can't attach a screenshot.


    02 Jun 2015
    1. User avatar

      Andrew Lui [Atlassian Technical Writer]

      Thanks Steve, fixed.

      02 Jun 2015
  29. User avatar


    Is it possible to have version hierarchy? There is a plugin but it is only available for the server edition. 

    It would be good to have this so that we can have multiple sub-versions of internal beta releases and then group all the sub versions to a main version when it is release to live.


    And when you merge versions, are the tickets still traceable with the original version that they were assigned to?

    23 Jul 2015
  30. User avatar

    Michael Manzo

    I have the same request as Sohan. Our version numbers are a.b.c where a is major release (alpha, beta, first commercial version, major upgrade); b is the minor version (adding a feature during a major release); and c is the build number. Product management would like to track only major and minor release numbers for product planning while engineering and operations want to know the build number in which the release happened. Having an hierarchy for release/version numbers would be an ideal solution.

    17 Aug 2015
Powered by Confluence and Scroll Viewport