|
History
| Log In
|
|
|
|
I also think it is necessary. We are using project version as marketing versioning scheme. So module versioning scheme is not corelated with project version, especially for heterogenous projects where components are developed&released with different pace. Without built-in mechanism of tracking component version we would have to increment project version for each component release (but we do not, for the sake of sanity).
I think that solution could be very simple - just ability to give a hint (line of text) what version of module we are talking abount filling up the issue form. Workaround with using multiple projects groupped together (as mentioned here JRA-3228) is unacceptable for very simple reason - one cannot suggest that some problem lies in multiple components/projects. Problem raised in many places, see duplicates.
component versionning would help us a lot. It will definitely increase the usability of component versionning under the controlling umbrella of Jira
 so voting eagerly for that feature. Kamil Regarding the votes on all the similar issues, this task collected a mediocre request from the user community (30 votes totally).
So, would it be enough to plan it for some "not so far away" releases? 3.6 or 3.7 may be? Kamil Kamil,
The schedule for 3.6 is packed already, so I doubt it will make it in there. As for 3.7, even we don't know what's going in that. We like to re-assess after each release to see what the community wants and the priority of issues. For a full explaination of how we schedule new features  .
Cheers, This would be a very useful feature for us too. For example, I've just been asked to create 100+ new projects for the reports relating to a new application being implemented here - each one will be released independently, hence the separate projects. If we could create versions for a component, we could create one project with 100+ components, each with its own version history. This would make the list of projects MUCH shorter and so easier to use.
Can you please tell us whether this is going to make it into 3.8/3.9/4.0 ? Thanks I agree, please make this issue a priority and implement it in the near future (next version?) I have the same problem here, i need to create too many projects to handle all versions of component that are actually in the same project. Because i deal with a big custom project for a client with dozens of individual component (programs, dll) that are part of the same project
The problem is, if i start my project structure like this, it will be a pain to transform all the projects into components when you'll finally release the feature. So i think i will create only one project and multiple components and disable the versioning for a while and wait for the feature. I hope it won't be too long. Ask all your friends to register and log in to vote for this issue I do think this is a major issue. Especially in software development industry where most softwares are object-oriented base. Our applications are build up by multiple components (.jar, .dll). A bug fix in 1 component does not require a full release of the whole application, but only the component itself.
Currently, we manage our components as different projects... By doing so, our reports do not reflect our real activities for one specific project. That being said, It is totally a + for JIRA, and for us, to have the feature implemented ASAP. Thanks, We use also differents jira project for the same product but different versions. I also want to manage 1 product in 1 "project".
But our products has different versions and each version has different components (each with its own version) . But also differents teams working at different releases (small en very big) and the next thing we should need are different schemes per product version. It make this issue more complex but i think ( for enterprice user), it makes jira much better. I would like to implement these feature in a total solution. (see JRA-12241) I would also to like that atlassian finaly make a decision if these issue will pick up or not. We have several groups that manage over 50 smaller applications. The simple components field doesn't allow the granularity we need in this case. The only true fix is to have a dedicated project for each application, which would become an admin nightmare. This request, or to allow components as cascading fields, would definitely help us. Vote!
I would like to see the following hierarchy as an option, with version ability at the Module level.
Project Some of our modules are pretty complex and we need to have a finer grain control. It would be nice to have this option on a project by project bases, just like you have with Sub-tasks being on or off. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Allow Versions of components
I think the lack of component versioning really is a major problem. One that I would like to see corrected as soon as possible.