1

Before production release we make few intermediate versions to help managing test-fix iterations, like:

  • 1.0-alpha1
  • 1.0-alpha2
  • 1.0-beta1
  • 1.0

[edit] Basically those intermediate steps help us relate to specific phases:

  • with comments like "it worked in alpha1 but it doesn't in alpha2"
  • it's helpful to filter issues that changed in specific iteration

After some time it gets messy to deal with so many versions and it seems good idea to merge all those versions into one (say: 1.0), but that would mean losing some historic details.

[edit] Is it correct to create those intermediate versions? Should they be merged after final release?

Improve this question
6
  • Your question currently lacks sufficient context. How are you using these version identifiers? Will you ever need the historical details? What information will you lose?
    – Todd A. Jacobs ♦
    Commented Feb 27, 2018 at 11:29
  • Why do you consider your alpha and beta "releases" as releases instead of pre-releases with Jira version tags? Why not call it 1.0? In my experience, alpha, beta, and release candidate are all pre-releases. Alphas are when end-to-end testing of a one or more pieces of functionality can begin. Betas are after a feature freeze but testing is ongoing. Release candidate is a stabilization phase that is wider than a beta. Your team or organization may have different terms, but you should probably be tracking against a true release and not alphas and betas.
    – Thomas Owens ♦
    Commented Feb 27, 2018 at 11:36
  • @ToddA.Jacobs Thanks. I distilled the arguments why I do those pre-releases and now I see that a little clearer.
    – dimril
    Commented Feb 27, 2018 at 12:24
  • @ThomasOwens So you say I should just create labels with pre-release versions (like "1.0-alpha1") and keep fixVersion 1.0 for all the issues? That seems right thing to do. It'll allow me to keep history which issue has been changed in which iteration and also keep version history clean :)
    – dimril
    Commented Feb 27, 2018 at 12:25
  • 1
    @ThomasOwens I guess I needed to change perspective a little. Sitting inside dev-team I considered pre-releases a big deal so I marked them as real release versions. Now I see that labels will do the job better, as they are internal and versions are external piece of information.
    – dimril
    Commented Feb 27, 2018 at 12:35

2 Answers 2

Reset to default
2

I recently asked this in person at a training, and was told that it is in fact good practice to use JIRA versions for alpha, beta, et cetera, because it means you can use the AffectsVersion and FixVersion fields to manage issues that are filed against these pre-release versions & make sure you get them all.

Improve this answer
2

After changing perspective I got to the answer I sought:

  • fixVersion field is for externally visible version and it should reflect public releases only
  • pre-releases (alpha, beta, RC) are just internal pieces of information - if you need to relate to it or use it for searching then labels are a better choice

Thanks to @ToddA.Jacobs and @ThomasOwens for helping me sort this out.

[edit] I found that Jira allows defining custom fields - I created fields "Affects pre-version/s" and "Fix pre-version/s" and it proved to be right thing to do. We may search using those fields and standard "Fix version/s" field remains clean.

Improve this answer
1
  • "pre-releases (alpha, beta, RC) are just internal pieces of information" -- this is not always the case. For many companies, these are also public releases.
    – Holistic Developer
    Commented May 10, 2019 at 20:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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