The release label creation at the RTC project area level
2 answers
looking at the help, I have to admit, it leaves a lot to be desired in explaining this feature.
The best hint i found is when creating a release from a build in Eclipse:
What this setting does, as far as I can tell is as follows:
It hides the release as selectable in the Found In work item attribute for anyone who is not a member of the project area or a team area within that project area.
If you change the visibility in the Eclipse client, it also says "Project Internal".
The reason why this is not on an individual team level is basically because releases have no direct relationship to a team area. They don't even necessarily have a relationship to a build. So there is no ownership that could be used.
This feature is meant to allow the project to create many releases on the way to their final one, but hide intermediate releases from external users, so that they can't file work items against it.
Comments
Ralph, Thanks for the clarification. I have 2 concerns.
To 1: I don't understand the statement. Releases are available to all teams in one project area. The releases Tab is only available on the project level. I can't see any relationship to a single team. Often one product is also created by various teams (e.g. DB, UI, Common).
To 2: I can't follow this and I have also experienced that what I expect a tool should do and what it really does is not necessarily a good match. I finally figured I have to follow how the tools are designed and potentially find ways to do what I desire based on what is available.
In RTC development, the releases tab mostly contains logical releases and also milestones e.g. 4.0, 4.0.0.1 M1,..... That keeps the list manageable.
To track work towards a specific milestone, track build work items are used. These are associated to build results.
It would be possible to use an attribute of type work item and a special work item type that specifies a release.
I agree there is room for improvement. Please file an enhancement request if you think this should be improved.
In our organization, we decided to have Platform(PF) as RTC project area and PF development,and application development (to support different customer)are becoming a individual team area. For e.g. Under one RTC project area (PF) we may different customer project like Ford, Hyndai, Honda, Nissan, etc... Because all those program are using that Platform and have different milestone. If we have 5 milestone and for 20 team area, it is totally 100 releases. In that case if we allow all the team members to see all the releases with in that project area, it is difficult. That is my concern.
I agree with your assessment. However, the tool is, as far as I know, working as described above. Maybe using a special work item type would make this easier. The problem will probably be to come up with a value provider that selects the work items a user should see.
[Ford] S1
[Ford] S2
...
[Honda S1]
....
At least, while the list will still be long, the user can scroll quickly to the release they care about.
The other thing you can do is make eager use of the ability to "archive" a release as soon as it is no longer relevant for current work.
Also, just wanted to make the usage is what you intend: This is the value that will appear in the "found in" field, e.g, for reporting defects. This is not the same as what is available for the "planned for" field.