JIRA branching and version numbers

Version numbers

JIRA version numbers  correspond to the branching strategy being used:

For example

There are unique version numbers generated per build. These uniquely identify the executable but can be too fine grained (noisy) for record keeping, testers, issue tracking, etc. They are in the developer world.Project managers can track version numbers at release or milestone level, such as "(bundle) version 1.1 was shipped to customer X on 1 Feb". These are in the project manager, dev manager view.The JIRA "fixVersion" and "AffectsVersion" can be defined to relate to the branch or bundle number of a particular product or component, not the build number and not the bundle number. The JIRA version number allows the tester to know what version a what product a bug was found in. The environment for that bug may be defined by the development stage it was found in ( for example UAT build #3). The JIRA version number has a defined meaning  to project managers, dev managers, testers and developers, across all stages of development ( dev, test, UAT, release)

Branching Strategies

The build and branching strategies are the key underpinnings of the JIRA and project views built on top of them. The goals of these strategies are to reduce dependencies, avoid double handling, and support  precise communication of bugs and work.

Here are some examples of branch strategies.

http://blogs.atlassian.com/2013/10/inside-atlassian-feature-branching-on-the-stash-team/http://blogs.atlassian.com/2016/05/prospering-with-long-lived-git-branches/