It's all about the answers!

Ask a question

What is the best RTC work item attribute type to use for a version number?


0
1
Michael Taylor (8865764) | asked Jun 27 '13, 12:52 p.m.

I need to store information like "1.20", "1.4", "1.10", etc.

I tried using the decimal type.  It worked well because it automatically placed the decimal point and it was easy to configure a default value of "1.1".  However, in situations where I need to document "1.10", the decimal type drops the trailing 0.  In my case, "1.1" is different than "1.10".

Is there a way to do this with the decimal type?  If not, what is the best type to use for this?

If I use a different type, can I still default the value to "1.1" and how hard is it to validate that the entered result is of the form "x.y", "x.yy", or "x.yyy" where x and y are numbers?  Can that validation be done easily through the RTC GUI configurations?


Comments
Ralph Schoon commented Jun 28 '13, 6:37 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Are you aware of this workshop? It talks about just this use case in Lab 4 as well as Lab 5.


Michael Taylor commented Jun 28 '13, 10:05 a.m.

Thank you.  No I wasn't aware of that workshop.  The workshop looks very interesting.

If I were to go through the workshop, would it lead to a different answer to this question or does the small string type still make the most sense for this?


Ralph Schoon commented Jun 28 '13, 10:11 a.m. | edited Jun 28 '13, 10:44 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Michael, the focus of the workshop (Lab3-5) is to make you aware of the Attribute Customization. You can just read it if you are only interested in these labs. We are looking into split it into two parts. Anyway, you would probably not come up with a different answer.

The only thing I am wondering is, that these numbers suspiciously look like version numbers that you might or might not want to maintain as releases (found in).



Michael Taylor commented Jun 28 '13, 10:24 a.m.

Thanks so much for the quick reply and for elaborating.  Your comments are helpful as we struggle to understand how to leverage RTC the way it is intended as much as possible.

These version numbers will be used to document Software Configuration Item versions for one of our legacy SCM systems until we can get migrated over to RTC SCM.  So I assume custom attributes still make sense for that.

However, I have a separate question open trying to figure out how standard RTC seeks to document the software release version an item is planned for (the release that will implement a work item) versus the release a defect was found in.  So I've been trying to understand what Found In, Planned For, the Release attribute/field, and now you just mentioned Filed Against are meant to be used for.  I'd appreciate any additional insight you can provide on that.

Reference the questions in the comment below:


Michael Taylor commented Jun 28 '13, 10:26 a.m.

https://jazz.net/forum/questions/117909/which-rtc-work-item-attributes-are-used-for-a-projects-timeline-iterations-and-various-planned-for-and-release-values?

    Still waiting for an answer on this one.  Is Planned For (timeline iteration) or Filed Against or some other field most appropriate for documenting the target release that will implement a work item?

https://jazz.net/forum/questions/117912/is-the-rtc-work-item-attribute-release-only-used-for-the-found-in-field?
    Are Found In and Filed Against both driven from the release attribute?  If yes, can Found In and Filed Against be saved with different values on the same work item?


Ralph Schoon commented Jun 28 '13, 10:49 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Hi Michael,

I had to edit my comment above. I meant 'Found In'.

All good questions, but hard to answer.
I tried to address some of the basics here: https://jazz.net/library/article/589

Planned For is an iteration (marked with 'A Release is planned...') to provide the temporal aspect.

An Iteration can be synonymous with a software release. However the release itself e.g. R1 M3 would be maintained in the releases tab in RTC and can be used in Found In. And these attributes have different values. Both correlate if you name the iterations with a similar name schema. E.g. R1 M3 for an iteration M3 in an iteration R1 on the timeline.


Michael Taylor commented Jun 28 '13, 3:23 p.m.

Wow. Great article.  I wish I had known about that four months ago.  Still I'm very happy to know about it now!

I see that Found In is of type "Deliverable".  And as you say, that is linked to the Releases defined on the release tab.  Does any other work item field use the Release information or the Deliverable type?

And the text seems to indicate some kind of logical association between a release and iterations.  Is there any actual relationship?

After considering the following (see next 1 or 2 comments), it seems like the Found In/release field is intended to indicate for which release an item is being worked on.  However after reading the last quote below, it seems like the Found In is meant to indicate in which release the problem was found not necessarily the release the problem will be fixed in.  Which is it?


Michael Taylor commented Jun 28 '13, 3:24 p.m.

From the article:

--------------------------

   "It is a common need to know for which release or version a work item has been created"

   "The work item's attribute Found In allows to select and set the release the work item was created for."

   "...it is only possible to select iterations that are planned to deliver something...by setting the A release is planned for this iteration property for the iteration"

"testers and others can use the release to express in which build/milestone they found the issue"

Ultimate questions:

------------------------

If I want to document the release a problem or enhancement request was found in, which field is most appropriate for that? 

If I want to document the release a problem or enhancement request is to be implemented in, which field is most appropriate? 


Geoffrey Clemm commented Jun 28 '13, 11:46 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

To document the release a problem was found in, the most appropriate built-in field is "Found In".   To document the release a problem is to be implemented in, the most appropriate build-in field is "Planned For". 
WRT the earlier comment's questions, to my knowledge, only the Found In field references the Release objects.
And although there is a logical connection between an iteration and the Release that the iteration is supposed to produce, to my knowledge, there is no way to actually create such a relation (beyond using the convention that the iteration has the same name as its corresponding release).


Ralph Schoon commented Jul 01 '13, 2:13 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

+1 this is indeed the case. You can have iterations in the release that are named like the release, but there is no logic built in to make a connection.

showing 5 of 10 show 5 more comments

Accepted answer


permanent link
Indradri Basu (1.8k1514) | answered Jun 28 '13, 2:07 a.m.
Hi Mike, I would probably go with Small String. I quickly tried a few things with 4.0.1 eclipse client, keeping in mind you want to set a default value like 1.1, a validator is needed for ensure the version number formatting and you want to avoid scripting.
Here is what I have done.
First I created an attribute of type small string.  Then from Attribute Customization, I added a default value and selected the provider as Single-Line text and set the configuration to 1.1.
For controlling the formatting, from Attribute Customization, I added a Validator of Type Regular Expression and set the regular expression to ^\d{1}\.\d{1,4}$, which means only digits are allowed, one digit before the decimal and 1 to 4 digits after the decimal. See the screen shot below


Then from the Types and Attributes, set the default value and the validator to the new small string attribute.
Finally, from the Team Configuration -> Operation Behavior -> Work Items -> Save Work Item (Server), add the Precondition, Attribute Validation. Refer to the screen shot below.



It's done. I hope this addresses your concerns.
Michael Taylor selected this answer as the correct answer

Comments
Michael Taylor commented Jun 28 '13, 3:50 a.m.

Thanks so much.  This looks like exactly what I need to do!  I will attempt this configuration on my JTS.  The detail and pictures you provided are greatly appreciated and will really help us get RTC going on our project!

Do you know of a good reference for the kind of notation you suggested for the validator? " ^\d{1}\.\d{1,4}$"


Indradri Basu commented Jun 28 '13, 4:35 a.m.

There are lots of regex tools available but this one looks handy to me


Michael Taylor commented Jun 28 '13, 5:06 a.m.

Thanks, again.  I have this working now just as you suggested.

If I wanted to force the first digit to be the number 1 instead of any single digit, how would I do that?  (example, 1.5 / 1.43 / 1.589 - not 4.3 or 2.5, etc.)


Indradri Basu commented Jun 28 '13, 6:00 a.m.

^[1].\d{1,4}$


Michael Taylor commented Jun 28 '13, 6:26 a.m.

Thank you.  That worked for me!

And this is one of the best answers I've received on the Jazz.net.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.