What is "released" as applied to a "version"

[Caroline Gordon]

I'm really confused about a fundamental question with versions and releasing a version.

Is a "version" a "sprint"?

What is 'released' - does this mean you created the version for testing or does this mean you are deploying.

I'm used to thinking of version as something finished development and ready for test, you test a number of mini versions before releasing one of them.

We are a small team so a simple workflow will suffice and I want to match up with Greenhopper as much as possilbe.

We are using scrum with 2 week sprints but I would like to be able to release to production during a sprint if we are ready.

I have been scouring the documentation but I don't see anything explaining the basic model/definition of versions and releases.

[Caroline Gordon · Accepted solution]

Thanks for all the help. I have this figured out now. The important concept is that 'released' means 'deployed'. Whether that is deployed to staging, prod or whatever.

What confused me is I am used to talking about 'release' to 'test' So a 'release' would be needed to transition from dev to test.

It all sounds a bit obvious in retrospect, but the point is release in JIRA means testing is complete, it is 'going out the door' whatever that means in your context.

[sclowes]

This is a little bit confusing depending on whether you use the Rapid Board or the Planning Board.

In the Rapid Board sprints are completely separate from versions. So you can easily run as many sprints as you like and pick and choose what to put in each release.

In the Planning/Task/Chart/Released Boards sprints are represented by versions, but versions are in a hierarchy. As Christian has said you can have several sprints that are part of one parent version.

Thanks,
Shaun

[Caroline Gordon]

I am using the Rapid board. I am going into the admin of releases and typing in our tag name, and setting it to be 'released' on the day we create the tag. That is our 'version', it is going into testing, it is not 'done' when I set it to 'released'.

I did start having a version hierachy, but actually I don't think that was helping and this sprint I haven't set it up.

We have serious constraints right now in that we can't define our own workflow in JIRA. This should be fixed soon and we will move to our own installation. We also don't have SVN integration working yet, that will come on our new installation. So some of my confusion could be that we have a pretty half baked system we are tryign to use.

Anyway, trying to state my question more clearly:

- should I set a version as 'released' when it is passed to testing? If not, when is it set to released and why?

- What is JIRA / Greenhopper doing with the 'released' information? In both Kanban and Scrum models?

- Have you published an example workflow for dev - > check in -> tag -> test and at what point the 'released' attribute gets set?

- There seems to be some conflict between continuous flow and the versions and releasing. I don't want to predict ahead of time which version a particular issue will be in, other than it is in this sprint. But within a sprint I want to know exactly which 'version' is in test, what fixes are in it and what isn't. Do you have some example workflows that offer some examples of this?

- I want to use the roadmaps (future release plan) but I don't want to edit every issue with a release name, and every time there is a replan to edit every one. It seems I would be better to handle this in a spreadsheet externally from JIRA? So this is about the high level view of release names, sprints. Is there some best practise example / paper about how to set this up?

[Caroline Gordon]

Thanks for the answers so far, really appreciate it. For some reason I still don't quite get it. ;-)

So, I want to state my question a different way. I am used to Borland Starteam, with the following workflow:

- mark issues as fixed with a fix version as 'next label'

- when ready to release, create a view label (like an SVN tag) which automatically populates every issue with 'fixed' 'next label' as 'fixed' and the actual label name you created

- this perfectly handles the scenario of ongoing development and a snapshot taken at a particular time and released to the next stage in your workflow (generally testing)

So how does greenhopper / JIRA handle this? Once we release we need to manually go and change the fixed in field? So always fill in the fixed in field at the moment you fix the bug, at which time you need to know the next release name (and have it configured as upcoming release). So far so good.

But then I want to use the roadmap feature, which relies on having the 'f, so I have to go and update every single issue every time I do some replanning?

Just having a conversation with myself here, but thinking i need to get into the release hierachy and use that as the roadmapping tool. So have a version N.0 which is a major say 3 monthly version name, that contains all issues but not which specific sub vesion they go under. Then as you start sprint planning, break that into say N.1 N.2 N.3 for each sprint and only change the fixed in field at the very point you fix it.

HOWEVER, I don't think the roadmap will work well then. I want to see a map out of the future sprints and what issues are ending up where and just bump them in and out as needed, which this won't do.

I'll go and experiment more with roadmaps and future versions.

Someone should write a book on JIRA and cover all this, I would buy it ;-)

[Christian Czaia _Decadis AG_]

Hey, basically you can define a version as you like. You could create a version (e.g. 1.6) create a sub-version (1.6.1) setting 1.6 as parent version (https://answers.atlassian.com/questions/40942/set-parent-version)in planning mode and create a sub-sub-version representing your sprint. That way you can release sprints as you like...So yes, a sprint is a version ...

Hope I understood your question correctly:-)

Cheers Christian