3

I've got a scenario. In my company, we used Jira as our tracking tool. Now, we have developed this mobile app which runs both on iOS and Android. We have decided to implement the iOS first. So, in our JIRA project, let's say the setup would be, I created myapp_jira_version_1 on JIRA which corresponds to the first build created by the iOS developer which says let's say myapp_build_1. As the project goes on, we can see that the Jira version is parallel to the build version as it increments. My question would be:

  1. Now, what if we will decide to start the Android development, and say we already reached build_version_10 on iOS and Jira_version_10 on Jira. In the 11th version, it is expected that there are Android related issues that would come. So, will it the iOS and Android issues will be merged with 1 Jira version?

  2. In this case, on one mobile app running on both Android and iOS platforms, is it a good practice to split them into two Jira projects? If this is a bad practice, could you give me solution for the first question?

Any comment/s from you guys are much appreciated.

Improve this question

2 Answers 2

Reset to default
1

If I understand correctly, you used the software version to name the Jira project?

My answer would be that No, this is not how I would manage it. I would not use Jira that way. I would either have one project that covers both systems or two projects, one for each. Which will be right for you will depend on additional details within your organization such as how the projects are linked, code they share, functionality they share, team that do the work, size of those teams, etc. I work at a place that does two releases a week for our product and we use one long-running Jira project for it.

Within 1 project that are several options that you could use to differentiate work. The correct one will depend on additional details for your organization. The ones that come immediately to mind are:

  • Epic - This can be useful to group a bunch of tickets together for whatever grouping you want.
  • Component - We've used this as a high level categorization of which team is doing the work.
  • Label - You can use this to categorize and tag tickets.
  • Version - I think Jira may have a version field(?). We didn't use it.
Improve this answer
1

"So, will it the iOS and Android issues will be merged on 1 Jira version?"

This is probably your core question. The answer would depend on many factors:

  • Do you care (will you do it) if Android and iOS release features at different times?
  • Do you semantic versioning, i.e. 2.0, 2.1, 2.1.1 and do you share sub version numbers for fixes?
  • How frequently do you release ?
  • Can you add an identifier, i.e. 2.1A and 2.1I to distinguish platform specific releases?
  • Can you add a field that indicates any Android or iOS specific tickets, but keep the general versioning as one project, releases may sometimes be simultaneous, e.g. 2.1.1A and 2.1.2I
Improve this answer

Your Answer

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

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