|
[
Permalink
| « Hide
]
Thomas Singer added a comment - 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, Rereading the title - I think build number should be build ID - i.e the value should any set of chars the user site chooses - it would be more flexible. If it happened to be a number on a particular saite all well and good.
Integration with Continuum would be great
regarding the title - I understand the concern re: "build number" - but I'm not a big fan of "build id" - how about "build label"?
It is only after using Jira in a real production environment with a separate QA/test department that I have realised how badly Jira is lacking here.
We run a rapid release cycle to QA so that they can refine their test specifications and prove major new functionality. So for example we have had 20 builds of one project in 4 weeks. This means we have a LONG list of version on the project. However if it wasn't for the long list of versions and ugly display paradigm this wouldn't be that much of a problem. What is required however is a combined releasenotes/changelog feature for actual versions vs. builds. I think we would be happy with a manual "add build to version" option, and for there to be a "Affects build" and "Fix in build" fields containing all the builds for each non-archived version. We would of course want Roadmap (the killer feature of JIRA) etc to function by both "by Version" and "by Build for version X". With this and proper nesting of projects as per JRA-5721, it is hard to see how Jira could be beaten. As a potential customer, I'm a bit concerned that it takes Atlassian so long time to implement such a simple feature. Is there anything I can do to speed up the process? What is the real problem here?
Hi Peter,
There is no real problem - only resources. We have limited resources and can only implement a certain number of new features in each release. As you can see, this next release (3.5) we are implementing the most popular With the number of votes, I can't imagine it will be too long before we implement it. Please see the linked foc for a full explaination of how we schedule new features There are a few steps you can do to influence Sorry I can't give more info on this specific issue at this time. Cheers, I am looking for a new bug tracking system for our company because our current system lacks a couple of key features required to manage enterprise software products. The "big three" for enterprise software product management are cloning (useful for tracking bugs across multiple releases, because some of your customers simply cannot not risk upgrading their mission-critical software with every release); subtasking (useful for developing multi-component products) and build numbers (absolutely essential for tracking quality; as well as letting your QC team, your sales support team, and your customer service tearm know when to expect a fix). Yes, there are many other important features, but typically most other bug tracking systems also support them to some degree. To re-iterate what others have said, I need to be able to
As for whether it is build number, label, or id, I can work around any choice, as long as the selection list sorts in meaning full way. E.g., build "100" comes after build "2" [For the record, in our shop we generate monotonically increasing build numbers as part of a nightly (or on-demand) process. Labels such as "beta 1" or "rc 2" or "SP3" are merely convenience labels associated with a particular build number, e.g., QC may designate build 478 to be our "rc 2"] So, while Jira seems incredibly full-featured and is clearly the best-suited candidate for our needs, it's hard, if not difficult, for us to justify the huge turmoil of implementing and training users on a new bug tracking system if the new system lacks key features that are causing us to want to switch in the first place. Note, the cost of Jira is not an issue... I have no problem with the pricing. Now, if I knew for certain that this feature will be implemented in the next few months, it would make the decision very easy! I would like to propose another way of relating the issue that's been resolved to its corresponding build:
We committing code, we currently insert in our subversion comment the issue id that was resolved. What I propose is to get the following integration with a continuous build tool: 1. The continuous build tool will, upon a commit, update its local repository. To summarize it, I think it is more convenient to log the resolved issue in the code commit than to have to indicate the build number (123.45 or next) when resolving the issue with JIRA. Sorry for the error in the previous comment:
When committing code, we currently insert in our subversion comment, the issue id that was resolved Can we expect this to be resolved in 3.5?
John.
3.5 is about to be released any day now. At the moment, unfortunately, I do not have a release date for this feature. Thanks, JIRA can be extended in several ways. In order to address this type of problem, I've created a JIRA service to poll periodically from the build automation system for recent successful build, and feed into specified project as released version.
At the time of finding new build and creating new released version, this service checks all resolved issues of that project and set the "Fixed In Version" (a custom field created automatically by this service) to be the new build if they satisfy these two conditions: Also another custom field "Download Links" will be created to track download links of each build inside JIRA. In this way, developer never worry about which build their fixes will come into, and QA will be happy that for a new build, they can search against the "Fixed In Version" property to easily find out what issues they should test in the build at hand. You may download source code of this plugin from http://confluence.atlassian.com/display/CODEGEIST/JIRA+QuickBuild+Plugin Hope it helps. Robin Any update on when this feature might get scheduled in?
Jira lacking this feature is by far my company's biggest gripe with Jira. We do lots of builds that need to identifiable for QA. We'll most likely add a custom field to hold the build number but it would be nice if Jira had this feature.
It's impressive how Atlassian can systematically shirk this issue for over 5 YEARS. I find that almost unbelievable. Perhaps this is what it looks like when a company has long decided that it doesn't care to listen to its customers but wants to appear that it does.
If your own issue-tracking system can't recognize the importance of a popular issue that has been left for too long then you should be losing more customers than just us. Hi JP,
Frankly, we've not been as great as we would like at responding to some of these long standing issues and we have admitted this to ourselves. Depending on your use case there are a couple of plugins that might be useful. As for this feature being addressed within JIRA, we do want to add this functionality to the product along with many of the other useful enhancements customers have requested. We are listening and with every release we try to enhance JIRA as much as we can. The next release of JIRA, 3.11, will add aggregate time tracking information across sub tasks ( I hope this answers some of your concerns. Regards |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
support for build labels within versions
