History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: JRA-4172
Type: New Feature New Feature
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Mark Chaimungkalanont [Atlassian]
Reporter: Austin Mills
Votes: 6
Watchers: 6
Operations

If you were logged in you would be able to see more operations.
JIRA

Request web service method to create new versions of a project

Created: 04/Aug/04 03:13 PM   Updated: 19/Mar/07 12:49 AM
Component/s: Remote API (SOAP & XML-RPC)
Affects Version/s: None
Fix Version/s: 3.2.1

Time Tracking:
Not Specified

Issue Links:
Reference
 

Participants: Austin Mills, Brian Krueger, G.Beilhack, Gary Piercey, Jeff Turner [Atlassian], Mark Chaimungkalanont [Atlassian] and Warwick Allison
Since last comment: 69 weeks, 6 days ago
Resolution Date: 06/Jun/05 04:16 AM
Labels:


 Description  « Hide
We use an agile development methodology and continuous integration, which can produce new builds as often as once an hour. It would be very useful to be able to track bugs on a per-build basis, rather than just by version, which is nowhere near the level of granularity that we would like (often a couple of hundred builds per version release). However, since currently a new version must be created by hand, we can't afford to do this for each build number. A web service that we could call to create a new version for a project would allow us to add this version to Jira as part of our build script. Then QA would know which issues it could expect to see finished based on the build number that we've given them, rather than them having to search through bugs to find out that information.

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Brian Krueger - 13/Oct/04 06:12 PM
This would be a huge benefit to us as well!

Jeff Turner [Atlassian] - 13/Oct/04 09:03 PM
I think we would need to introduce the concept of a 'build', or sub-version, otherwise the drop-down version fields would get unmanageably long very quickly.

Austin Mills - 13/Oct/04 11:25 PM
Actually, even without that functionality, it would not be too terrible for us as we would just make liberal use of the merge and archive functions. The ability to do sub-builds would be nice, though.

Brian Krueger - 14/Oct/04 02:22 PM
Liberal use of version and merge functionality would of course work, but it would be very labor intensive. Because you can track issues related to a version, if we had the ability to do (auto-generated) build numbers, we could use JIRA to provide build notes. Please give serious consideration to build functionality, as the "hard way" described above is most certainly not the best way.

Jeff Turner [Atlassian] - 15/Oct/04 12:38 AM
By the way, in 3.0 the RPC functionality has been broken out into a plugin:

http://confluence.atlassian.com/display/JIRA/A+Brief+Guide+To+JIRA+Plugins

The source for the RPC plugin in JIRA 3 is online at:

http://repository.atlassian.com/atlassian-jira-rpc-plugin/distributions/

It's now possible to create issues via SOAP/XML-RPC (not yet versions, unfortunately).


G.Beilhack - 17/Feb/05 03:14 AM
I have just read the current SOAP WSDL file . I've noticed the getVersions and updateProject operations , I could use an 'addVersion' operation as we too very often have to add new versions to a project .

The last comment to this item is of Oct 2004 , what are the current plans for implementing this operation ?


Gary Piercey - 02/May/05 09:41 AM
We have been trying to integrate our build script with Jira and track build numbers in the version field as well. This is a very important feature for us so we hacked together a temporary solution and we are still trying to find better options. Is there a timeline for this RPC addVersion feature? It looks like there is some demand for it...

As a temporary solution we managed to perform an automatic version update through an auto-generated Jelly Runner script. The Jelly script is generated and placed in a shared folder on the Jira server by the build script and Jelly Runner is setup as a service but this is a hack until we get the RPC option. We run the risk of the script being overwritten before the update occurs so this is not optimal but it works as a temporary workaround. A sample script follows:

<?xml version="1.0" ?>
<JiraJelly xmlns:jira="jelly:com.atlassian.jira.jelly.JiraTagLib">
<jira:Login username="YourUsername" password="YourPassword">
<jira:AddVersion project-key="ABC" name="BuildNumber" />
</jira:Login>
</JiraJelly>

Hope it helps some of you who are waiting on the RPC functionality...


We've now added addVersion to the SOAP interface

Warwick Allison - 19/Mar/07 12:49 AM
No way to set the release date with Jelly tags though.