Difference between revisions of "Development:UsingJira"

From Jalview Wiki
Jump to: navigation, search
Line 4: Line 4:
 
== Improvements to JIRA workflow ==
 
== Improvements to JIRA workflow ==
  
# Release targeting for patches. At any one time there are several releases in play:
+
These are some notes on future JIRA configuration and how the Jalview development community should use JIRA.
; Release tags
+
; current stable: The current branch available on the Jalview website.
+
; next-release: The next release which is is in alpha/beta.
+
; future-release: The development branch build.
+
  
 +
# Release targeting for patches. At any one time there are several releases in play:
 +
#; Release tags
 +
#; current stable: The current branch available on the Jalview website.
 +
#; next-release: The next release which is is in alpha/beta.
 +
#; future-release: The development branch build.
 
# New issues need to be assessed and targeted to a release before anyone should start coding.
 
# New issues need to be assessed and targeted to a release before anyone should start coding.
 
#* Bugs and feature requests should be verified and prioritised as:
 
#* Bugs and feature requests should be verified and prioritised as:

Revision as of 10:44, 24 January 2014

http://issues.jalview.org is the Jalview JIRA issue tracker, which is provided to us through a free license from [Atlassian].


Improvements to JIRA workflow

These are some notes on future JIRA configuration and how the Jalview development community should use JIRA.

  1. Release targeting for patches. At any one time there are several releases in play:
    Release tags
    current stable
    The current branch available on the Jalview website.
    next-release
    The next release which is is in alpha/beta.
    future-release
    The development branch build.
  2. New issues need to be assessed and targeted to a release before anyone should start coding.
    • Bugs and feature requests should be verified and prioritised as:
      hotfix
      These are critical patches and minor fixes that cause minimal disruption. They are worked on as branches from the current release that, if necessary, are merged onto other release branches as needed.
      nextrelease
      are more major patches and new features that change the users experience, and affect compatibility with previous releases in some way (ie require a change in semantic version number due to file format or API change). They are worked on as forks from the nextrelease branch and would normally be merged onto the development branch.
      futurerelease
      these are substantial work packages that involve concerted design and development effort, and introduce major changes to the system (ie creation of a new release series due to API and project/datamodel change).
      spike
      these are experimental/ad-hoc patches to experiment with new approaches/concepts. Any code produced may or may not end up in a future Jalview release, but creating them should inform the design and development of future Jalview releases.
  3. Developers *MUST* assign a bug/issue to themselves before they start working on it.