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 '20 at 0:14
  • @ToddA.Jacobs Because it seems like a project will never be finished until some product is closed forever.
    – JJJohn
    May 16 '20 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 '20 at 22:21
  • @ToddA.Jacobs Here is a related one
    – JJJohn
    May 17 '20 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.

  • 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 '20 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 '20 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 '20 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
    – baye
    May 16 '20 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.

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.