|
History
| Log In
|
|
|
|
You are right - the custom field will not work for everybody.
> In our current system the issue effectively forks if it goes into more tnat one system and from then on the wrk flow is followed independantly for each build. This is particularly for 1st and third level support. If we are working on different branches then we clone the issue, however a particular fix (i.e. the identical code) may be included in both a hot fix and a subsequent rollup, the status should be tracked independently if this case and should follow the full workflow. We don't actually create a new issue in our current system in this situation - it simply allows the post-build work flow to be followed for however many builds include the change (and it is can be simple to implement)
How about creating sub-tasks on the fixed issue? Each sub-task can have its fix-for version set to the build including the change. You could even have a custom workflow on the 'Fix deployment' subtask type if necessary.
More thoughts on fix deployment + subtasks at http://forums.atlassian.com/thread.jspa?messageID=250096788�
 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 issue reaches code complete it cannot be changed by the developer unless it is reopened. '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*. You have 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. The link in the previous comment did not work! Giles,
Please try this link: I believe sub-tasks would be the best answer for your needs, and you can maybe simply your process by having these sub-tasks autmatically created in post-functions that create sub-tasks based ion your fix-for field. Let us know if you have more questions or suggestions after reading the above forum. Cheers, I've looked at this thread - handling issues in different releases branches (i.e. on different lines of development) is not a problem, either cloning or sub-issues could be used quite successfully. - we actually clone issues in our current system because the developers' consensus was that it would be easier to handle this way, although our system would handle mutlple releases under one issue.
My concerns lie in the situation where code on the same release goes into more than one build - it can end up in more than one hotfix because if a number of hotfixes affact the same code we try to roll them up., so for example it hotfix 1 and hotfix 3 both affect libcon.so, hotfix 3 will include hotfix1, and we will obselete hotfix 1. If both of these changes are on the mainline the will at some point be included in a patch release. We record both release and build, and both are neccessary. The build the developer won't know when he has finished with the fix. We populate it at build time from the build. using the script, so the generation of subtasks is going to be triggered at build time. A build represent a version of the system that is test and (maybe released). But we want to know that an issue was fixed in a particular build, The testers know what they are going to have to test, and the support guys know that a particular release or hotfix will solve a customers problem. To me 'fix-for' sounds like a target release, but do you have a field to record the actual release. It may be useful to know that a fix planned for 3.04 was not included, but later made it into 3.0.5, only having the fix-for risks losing info. In the thread it was implied that subissues cannot have subissues, if that is the case, then we wouldn't be able to use sub-issues if it turned out that subissues were the best way to handle different releases codelines rather than cloning. What kind of interatction would there be if we had say, documentation, handled as a subissue if subissues where also used for build tracking. Workflow example from a customer....
The heavy line is the ideal workflow. So you can see that from build onwards there is quite a bit of of workflow after build. The issue is able to follow that workflow for each build independantly. Great idea to submit a best practice suggestion
 , especially to the build hot topic issue within JIRA - thanks to Mike.
This issue could be the first linked to JRA-3845. What about adding a Component best practice to be able to find best practices (or tag existing) - or do you prefer to add a section to http://confluence.atlassian.com/display/JIRA/Home |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Fixes at different times across multiple versions / branches - best practice & custom field
If you want to implement CM processes then you need to be able to apply whatever workflow would apply post build to each build which includes the issue. Almost all issue trackers assume that the issue is effectively complete when the developer has finished with it although when testing has been done. But if, for example, a fix is included in a hotix and in a subsequent rollup release you need to record what happened in both builds, since the software with which the fix is built is different..
Secondly if you are using a CM process then the release itself is a controlled item and you have to be able to show its status and that of its components.
In our current system the issue effectively forks if it goes into more tnat one system and from then on the wrk flow is followed independantly for each build. This is particularly for 1st and third level support.