|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Thomas Singer - 13/Aug/02 08:40 PM
Wouldn't versions like "1.3 rc 1" help you?
as I said in the description, it would be too cumbersome - we'd end up with WAY too many versions. in the weeks building up to a release, we tend to do a lot of builds that can't even be rightly called release candidates; but QA still needs early access to them and needs the ability to see if a particular bug is fixed in that build.
Does the current setup - archiving and merging versions - suit you for this purpose?
You can add a version, and then when it is released, merge all the QA versions into one? well, I can't quite tell, I can't figure out how to edit the project versions on 2.0RC3. I read a couple of the notes in the list and I really think the separate notion of a build is helpful - it would allow us to mark a feature as "fixed" in "next build". then when I do a build, it takes all those for that release with "next build" and associates it with the build number.
that would also greatly simplify our workflow. we're currently using fake users, i.e. "_build", "_qa", etc. because we can't simply separate when somethign has been fixed and is awaiting build, from when something is fixed and awaiting QA. plus, QA has a hard time knowing what was fixed in which build, etc. glad to see this scheduled. here are my implementation ideas: build numbers would enabled on a per-project basis. if enabled, build numbers would be created by someone with project administration privileges. build numbers would have to be attached to a particular release. when creating a build number, a list of issues where "fixed in release=(the build number's release) && resolution=fixed and buildnum=null" would be displayed, each issue with a checkbox automatically selected. then specific features could be added/removed from the list.
it would also have to be possible when editing the issue to change the build number, and changing the build number would be required when changing the fixed-in release. also, I would think this feature would benefit from a new status of "built", for something that had been resolved (which had no build number) and then assigned to a build number.
adding more detail based on a separate conversation with sales@atlassian.com...
For starters, developers need to be able to select a build number when fixing issues... 1) need a new table to contain build numbers, which would be attached to versions. i.e. the build table will have a required foreign key to the version table. When the build engineer creates a build, he/she goes into an admin screen for that project, selects an unreleased version, types in a build number and clicks "create", which brings up a screen showing all fixed issues with null build numbers - in reverse order of resolved date. Each line would have a checkbox (default checked) that would allow the build engineer to specifically exclude any issue (such as a late-comer that had been fixed after the build was actually done). This last part can be optional if it’s a ton of work - we could work around the situation if something snuck in. As I think about it, we probably don't need a new status – we can add a search based on "resolved issues where build number != next". Of course, it would be extremely helpful to make this visible from the browse project screen, by adding links under the versions for the most recent build number (if any) and "next" (if any), in other words (using our own release codewords for an example): — Aim 0 Ajax 40 Akron 14 Alias 4 Where clicking on aim, ajax, akron, or alias would work just like today, showing a list of all open issues for that version. Clicking on "build 045" would show the items fixed in that build of aim and clicking on "next build" would show the items fixed but not yet built in ajax. Alternately, a "BUILDS" section would be useful rather than mixing it in with versions, and you'd only show the most recent build (and "next") for non-released versions. Obviously for people who don't need all this, you'd want an admin screen to toggle this feature off just like you do for time tracking. Just to throw my two cents in. I need very similar functionality. The only difference is that I use an automated build process but otherwise I'm need the same stuff as Tim. That is, I need a seperate build number for each "Fix for Version". And I really would need a status of "Fixed,Checked-In, Awaiting Build" or something like that. So when an item is returned to the reporter/QA, they know they do not have a build in which to test the fix.
Tim talked about a way for a build engineer to mark item's "Fix Build". I need a way for an automated process to do that. We have builds scheduled everynight. Right now, with our old bug system (DevTrack), we handle this through some quick and dirty programs we wrote that connect to the bug database and update a custom field that we use as the build number. The ultimately awesome solution (for me anyway) would be a SOAP/WebService thingy that allowed me to pass in a version id or number and a build number and the process would mark all items with the status of "Fixed,Checked-In, Awaiting Build" for that passed in version, with that build number. we do auto builds too, but only for tests; our QA builds are manual, but that's a great idea.
an alternative to a web-services implementation (unless that's easy with the most recent version) would be to the REST approach - simply publish the specs on the HTTP POST that the web browser would send to create a new build number and assign all resolved-but-unbuilt issues to it. then any script or java class could easily be configured to make the post. I agree that handling builds is an important. Here are some of the things that come to my mind:
1) If the build engineer doesn't add issue X to the build, then Issue Y, which is dependant on issue X, cannot be added. Same if Issue X isn't ready for QA. 2) We would like to have a hierarchy of builds. We do an internal QA build and an External QA Build. The external QA only contains issues that have passed internal QA. 3) Any aggregating needs to take into account that Issue V will probably occur in build 5 and 7 and 12 since it keeps getting failed. Also, it would be good to allow builds to be accessible only to specific group.
This feature wasn't done in 3.0, and is still in the to-do basket. The cascading select list in 3.0 might meet this need for some people, but wouldn't be integrated into the reports.
I have to add a version for each build that goes to QA. I have to do this with somewhat of a naming standard, but this becomes a real pain when reviewing the change log as only 3 'versions' are shown without showing them all. We may have 6 builds go to QA for version 1.31.0.
That's my story, I don't have the innovative solution If the build numbers could be auto-generated, that would be very useful.
We need this feature badly, please plan to fix it in the nearest release.
Not having a build as a recognized entity in the system, including:
is a major problem for our adoption of Jira as a min issue tracker tool. Please don't hesitate to contact me if you have any questions about our use cases. Unfortunately we will not have time to address this issue for JIRA 3.2 as it is not straight forward to implement. There are quite a few major improvements in JIRA 3.2, such as configurable screens per workflow transition, tabs on field screen, multi-project/issue type custom field, etc.
We will return to this issue when we draft out the implementation details. some of the comments above have added features beyond my original request (now 2 1/2 years ago!) but with all the workflow and plugins added, I think what I originally requested could be easily implemented today:
1) a workflow transition that assigned the build number to "next" when an issue is resolved/fixed.
2) an XMLRPC plugin that executes a search for all issues with a given version and a build number of "next" and for each issue sets the build number to the provided value
one further comment - obviously this would mean decoupling build numbers from versions. that would be nice of course, but isn't as much of a requirement for what I need.
Tim,
Thank you for the comments. It is not possible to update the fix version with the current update issue field post function as the issue's versions are not stored in the issue db table. However, of course, it is possible to write a post function that does this. Conditional post functions can be created as well, using conditional results in OSWorkflow (http://www.opensymphony.com/osworkflow/ If you do not mind we will keep this issue to represent adding functionality for separating build numbers from versions. Thanks, by all means keep it as-is... if you make it a first-tier part of the product that's way better; I was just suggesting a wokraround for people who need it now (this one keeps getting scheduled and then pushed back)
My 2 cents, I am really dissapointed that this issue seems to have become the red-headed step child of issues. It seems this issue is constantly scheduled for the next release, only to be rescheduled to the next next release when work begins on a new version.
This is the only feature that I need in JIRA. I have not upgraded my 2.6 installation of JIRA because most of the changes made don't make much of a difference to me. The lack of build numbers for issues means that JIRA doesn't mesh with my build system. My QA department can't ever be sure when an issue is included in a build. My support department can't tell if a particular customer has a build that fixes a particular issue. Chris,
Which build system are you using? We have integrate JIRA with DamageControl, which uses the CVS commit integration to tell you which build a particular cvs commit was built in, and by extrapolation, which JIRA issues have been fixed. Is it possible to do something like this? This is an automated process, and would not require and human intervention. WOAH!
I cannot imagine that the 40 people who voted for this issue will go and find 40 different solutions to the problem based on their build systems. This needs to be handled by JIRA. Simple example: Please stop trying to address the problem with workarounds. Brian,
We will implement this feature, however we are trying to help our customers with immediate workarounds if possible. However, as we have 1176 open feature requests, we can not implement every feature in every release. We do not try to address problems with workarounds, but we do try to inform our customers of all the options available to them. Cheers, I'm bummed this is no longer going to be in 3.2, hopefully it will be in 3.3?
I just realized that this was descoped for 3.2. This is the biggest issue we have right now, and causes confusion with tech folks and users on a weekly basis. Call it "build numbers", call it families, call it grouping. Something really needs to be supported in Jira that doesn't require customization. The problem is that we need to keep this all at the Fix Version level. To do that with customization would require extensive changes to the guts of jira, and I think all of us try to avoid that much coupling for fear of future upgrade problems.
So this was planned for 3.2 before, but it is now not even planned for 3.3?
It's in the top 15 unscheduled issues. How high up the list does an issue have to get to become important enough to schedule? For that matter, most of the top 10 seem pretty important as well. I don't want to be a big whiner or anything, but what are the criteria? Scheduling an issue used to mean "we should really look at this for version X", but we discovered everyone else interprets as "I can tell my manager this will be done in version X". So we are setting the fix-for version more sparingly these days. It doesn't mean popular issues like this are off the radar - just that we haven't yet done 3.3 planning. Criteria are the usual mix of architectural, popularity and 'strategic direction' considerations.
We have a target release which is the release a developer is shooting for - the actual rease/build might be different and needs to be recorded. But We probably need to sort out some terminology .
The release in which an is found is different to the target -release which may differ from the actual release. How about: We don't bother to record that a fix was included in a recut, only that it went into a build. An issue is not complete until it reaches a termination status. - for example tested_ok, duplicate, withdrawn, rejected etc. For us if an issue is tested OK then we known what build it is in, and by extension when it became available to a customer. Prior to release of a new release to a customer we do a number of beta builds, b1, b2 etc. After GA release we treat each hotfix and patch release as a build. open->open for coding -> code complete -> built ->tested failed however bad stuff happens so the fix is reopend, fixed again and the build recut: open -> open for coding -> code complete -> built -> test failed (reopend for coding) -> code complete ->built -> tested ok Note: Once an uissue reaches code complete it cannot be changed by the developer unless it is reopened. This corresponds to Chris Grosses 'ready to build'. 'built' implies ready for QA etc. We currently record release and build so aggregation would not be a problem. To find all fixes in a release - search by release. To find all fixes in cluded in hotfixes based on, say, v5.2.1 (v5.2.1.1/2/3....), search by builds i.e V5.2.1*. It has been suggested that we use sub-issues for this - very definitiely a workaround and I suspect rather cumbersome. In my current system we have a table with issue, release, build and status columns this is joined with the issue table and as builds are added the issue effectively forks. Very simple. Ref Adam van den Hoven comments: We identify issues to be included by reference to the previous code baseline and the development tip using a script.. We can identify the dependencies he is worried about using another script (this will also identify orphan issues) and then determine how we are going to handle them. We (almost) never take work in progress and code freezes are consequently short, typically the time to branch the code. Trying to work out the depnedencies from the issue tracker is difficult, probably impossible even to do it reliably. Please see comments on: JRA-7886.
Also, Cheers, | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
New Feature
Open
Major
support for build labels within versions
