It has been suggested here that instead of one project and assigning versions using the affects/fix version fields, that we have a different project for each major release version of the product.
I cannot find any examples of JIRA used in that way. Do you know of any and what are the benefits or pitfalls of separate projects per major release version?
JIRA is used in several different ways by teams to meet their specific requirements and address different use cases.
Having a separate project for each release can result in additional maintenance - user roles, components, etc.
Components and Versions are project specific. So if your team is using components, every new release is a new JIRA project that requires you to setup all the components again. Same with versions. If you want to be able to track an issue for an old version that will be fixed in a new version, this is easy to do in a single project where you track multiple versions.
That is just a gist and my thoughts. I would recommend evaluating both the approaches and identify the pros and cons before adopting a particular strategy.
We are already set up as one project, multiple versions. However, we have not diligently used the version fields. My opinion right now is that we should be more disciplined with those fields rather than have a version-specific project.
One of the reasons I see to stay with one project is that we have several other projects for system requirements, release notes, hazards, and such that use the version fields to identify which releases apply...and putting everything in one project means we'd have to copy those items forward so there would be manual work to re-write some of them if we copied them too soon and they changed in the previous version.
But I do like the idea of having one project with everything and if we need to know what happened, it's in that project.
We are a medical device company so documentation is a huge piece for us. It's going to be a fight between what is easiest day-to-day (probably one project with multiple versions and the separate projects for "document" pieces) and what captures our information for a release for full reporting and audits (a single version in one project).
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs