Details

    • Feedback Policy:

      JIRA feedback is collected from a number of different sources and is evaluated when planning the product roadmap. If you would like to know more about how JIRA Product Management uses customer input during the planning process, please see our post on Atlassian Answers.

      Description

      Atlassian Update – 31 December 2015

      Hi everyone,

      Thanks for voting and commenting on this issue. Your feedback is key to helping us understand how you use JIRA so we can continue improving your experience. We have reviewed this issue over the last few days; however there are not currently any plans to implement this suggestion.

      This request is in a simlar position to JRA-846: We absolutely understand many the logic behind many of the requests for versioned components, but we strongly believe that our focus should be on making JIRA simpler and easier to use. Simply put, versions for components is likely to add complexity on a conceptual level, at a technical level (more bugs and slower performance) and will lead to a more confusing UI.

      Please remember that jira.atlassian.com is one of many inputs for the JIRA roadmap. You can learn more about our process here.

      I understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions.

      Regards,
      Dave Meyer
      dmeyer@atlassian.com
      Product Manager, JIRA Platform

      Original request description:

      I am a JIRA Administrator responsible for configuring it for complex development environment. Just like the entire project, the components also have their version number. Many times we have projects made up of multiple smaller applications, DLLs or modules. Each component in JIRA should have a list of versions just like the project. That way will be able to release and schedule versions of components.

        Attachments

          Issue Links

            Activity

            Hide
            sremiszewski Stan Remiszewski added a comment -

            I am a newbie to JIRA. My approach is the assign EPICS to define the subcomponents/modules of the project and use versioning on EPICS to assign the modules to a release. Tasks to be complete (i.e. module features) are then created within EPICS and subtasks can be created within the tasks. In the Backlog view EPICS and tasks are assigned to levels and easily filtered. In report view EPICS are captured and estimates are visible by EPIC, Version and individual, assigned to and individual tasks. I do not see the immediate value in components. Considering they are like projects with the benefit of actually being projects JIRA doesn't do much with them that adds value for the complication of another layer. BUT... I am willing to learn...

            Show
            sremiszewski Stan Remiszewski added a comment - I am a newbie to JIRA. My approach is the assign EPICS to define the subcomponents/modules of the project and use versioning on EPICS to assign the modules to a release. Tasks to be complete (i.e. module features) are then created within EPICS and subtasks can be created within the tasks. In the Backlog view EPICS and tasks are assigned to levels and easily filtered. In report view EPICS are captured and estimates are visible by EPIC, Version and individual, assigned to and individual tasks. I do not see the immediate value in components. Considering they are like projects with the benefit of actually being projects JIRA doesn't do much with them that adds value for the complication of another layer. BUT... I am willing to learn...
            Hide
            schrepfler1 Srđan Šrepfler added a comment -

            What I do is apply a convention, I prefix the version with the component name and then I use the capability where I can assign multiple versions to a ticket.

            Show
            schrepfler1 Srđan Šrepfler added a comment - What I do is apply a convention, I prefix the version with the component name and then I use the capability where I can assign multiple versions to a ticket.
            Hide
            bpeikes Benjamin Peikes added a comment -

            Can Atlassian please provide guidance on how to deal with long term multi-component projects where there are multiple versions of each component? I'm not sure how we can continue using the product if versions are at such a high level. Jira is already an extremely complex product, stating that component versions are not being supported because it would make the product too complex is simply avoiding a shortcoming of the product.

            Show
            bpeikes Benjamin Peikes added a comment - Can Atlassian please provide guidance on how to deal with long term multi-component projects where there are multiple versions of each component? I'm not sure how we can continue using the product if versions are at such a high level. Jira is already an extremely complex product, stating that component versions are not being supported because it would make the product too complex is simply avoiding a shortcoming of the product.
            Hide
            mike.eldridge Mike Eldridge added a comment -

            I echo these comments made above:

            If I may be so bold, this is a case of knowing your customers, a large proportion of whom will be Engineers and thus able to handle cognitive complexity quite easily. Jira isn't - and shouldn't try to be - Trello. Henry S

            Personally, I create versions in JIRA which include the component name. Tamsin Slinn

            Making a software easier to use don't mean less functionality. Florian Rubin

            We have a lot of projects wherein components are clearly delineated between front-end (mobile app) and back-end (API). We require separate release tracking for them because the release process differs so substantially (app store vs bamboo deployment plan). We're already abusing version numbers by inserting the component names into them. It's cumbersome and difficult to plan releases that need to happen in lockstep (e.g., breaking changes that require semver-major bumps).

            Since JIRA has been segmented into JIRA Core and JIRA Software, I expect Atlassian to better serve their engineering customers with JIRA Software. Imbuing a piece of enterprise software with new features is something we expect. We want more functionality; not less. Quite frankly, Dave Meyer's message reads as an excuse. "It adds a modicum of complexity and raises a number of other issues with respect to user interface we have to think through, so we're going to take the easy way out and not do it."

            It's become the norm for Atlassian. They deliberately dumb down their software in order to reach a broader audience to boost their sales. Good for them, but it leaves loyal customers like us out in the cold. We pay Atlassian for an enterprise solution for managing complex software projects. Why should we continue to pay for annual maintenance when Atlassian never improves the feature set?

            Show
            mike.eldridge Mike Eldridge added a comment - I echo these comments made above: If I may be so bold, this is a case of knowing your customers, a large proportion of whom will be Engineers and thus able to handle cognitive complexity quite easily. Jira isn't - and shouldn't try to be - Trello. Henry S Personally, I create versions in JIRA which include the component name. Tamsin Slinn Making a software easier to use don't mean less functionality. Florian Rubin We have a lot of projects wherein components are clearly delineated between front-end (mobile app) and back-end (API). We require separate release tracking for them because the release process differs so substantially (app store vs bamboo deployment plan). We're already abusing version numbers by inserting the component names into them. It's cumbersome and difficult to plan releases that need to happen in lockstep (e.g., breaking changes that require semver-major bumps). Since JIRA has been segmented into JIRA Core and JIRA Software, I expect Atlassian to better serve their engineering customers with JIRA Software. Imbuing a piece of enterprise software with new features is something we expect. We want more functionality; not less. Quite frankly, Dave Meyer's message reads as an excuse. "It adds a modicum of complexity and raises a number of other issues with respect to user interface we have to think through, so we're going to take the easy way out and not do it." It's become the norm for Atlassian. They deliberately dumb down their software in order to reach a broader audience to boost their sales. Good for them, but it leaves loyal customers like us out in the cold. We pay Atlassian for an enterprise solution for managing complex software projects. Why should we continue to pay for annual maintenance when Atlassian never improves the feature set?
            Hide
            bpeikes Benjamin Peikes added a comment -

            I fully agree with Mike Eldridge. I understand if Atlassian wants to keep the software backwards compatible, i.e. keep the current "version" methodology attached to the product. I don't see any reason that a "component version" field couldn't be added. As a matter of fact, we've added many extended fields just to support component versioning, but it doesn't feel right.

            Show
            bpeikes Benjamin Peikes added a comment - I fully agree with Mike Eldridge. I understand if Atlassian wants to keep the software backwards compatible, i.e. keep the current "version" methodology attached to the product. I don't see any reason that a "component version" field couldn't be added. As a matter of fact, we've added many extended fields just to support component versioning, but it doesn't feel right.

              People

              • Assignee:
                Unassigned
                Reporter:
                jason nethercott Jason Nethercott
              • Votes:
                624 Vote for this issue
                Watchers:
                350 Start watching this issue

                Dates

                • Created:
                  Updated: