In Software Project Management, Software versioning uses a convention like this

enter image description here

For example, skype 6.26.2 and skype 6.26.1 are different versions of the same App.

“Project” is the highest level container in Jira.

when project skype 6.26.1 is delivered, Should I create a new "Project" in Jira, to manage the development of skype 6.26.2?

  • 2
    Why not use the "target release" field? – Todd A. Jacobs May 16 at 0:14
  • @ToddA.Jacobs Because it seems like a project will never be finished until some product is closed forever. – JJJohn May 16 at 22:20
  • @ToddA.Jacobs Thanks for you comments. What is you best practice? Put "6.26.1" and "6.26.2" in the same project? How about "6.25" and "6.26"? – JJJohn May 16 at 22:21
  • @ToddA.Jacobs Here is a related one – JJJohn May 17 at 1:11

In Jira, I've found that a Project best maps to a software product. This enables more efficient use of the Releases and Components functionality. By using the Fix Version field on issues, you can target work toward a particular Release and then use the Releases view to track progress. Internally, to your organization, you may treat a release as a project, but the use of the Fix Version field, along with labels and issue linking, is what you would use for monitoring scope and tracking progress.

By using a single Jira project, you also enable the use of Releases to track Affected Versions. Often used for bugs, this lets you track which released versions a bug is found in. If you split the work up across multiple Jira projects, this wouldn't be possible.

| improve this answer | |
  • Thank you. Does "to track Affected Versions" mean this situation, some bug found in skype 6.26.0 and fixed in skype 6.26.2, so "Affected Versions" are 6.26.0, 6.26.1? – JJJohn May 16 at 22:17
  • @JJJohn As long as it existed in 6.26.1, then yes. In most cases, I suspect it would be correct. I can see a few cases, such as if 6.26.1 disabled the feature and 6.26.2 reenabled the feature with the fixed bug, where it may get odd. – Thomas Owens May 16 at 22:31
  • Thank you. A bug is found in 6.26.0, then disable the feature in 6.26.1, and then reenable the feature with fix in 6.26.2. Is this a common and acceptable way to deal with bugs? – JJJohn May 16 at 22:47
  • Yes,that's very common in case of a bug is found but you can't fix it quick enough in coming release, Then the best way to handling it is have it disabled first to stop bleeding – Baiyan Huang May 16 at 23:03

In my experience, the "patch" number normally means exactly that ... the latest set of "bug fixes" and maybe "trivial enhancements." Therefore, I would treat these as a new major milestone of the existing project. "Minor" releases might be treated the same way.

However, in all cases it's very important to consider what your teams actually mean by these numbers.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.