0

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?

  • 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 Feb 27 '18 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 Feb 27 '18 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 Feb 27 '18 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 Feb 27 '18 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 Feb 27 '18 at 12:35
1

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.

0

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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