This document outlines various processes around the day to day and release to release development of Hudson. It does not cover the actual process of becoming a committer on Hudson (this is covered by the Hudson Software Process) or the mechanics of building Hudson from source which is covered in the Wiki. Furthermore this document only covers the processes relating to the Hudson core and does not apply to non-core plugins which may choose to adopt the same process if they wish or may use some totally different process that suits the style of the relevant contributors.
The development processes assume that the following logical roles exist within the Hudson community universe, an individual may hold one or several of these roles:
Any comments you have relating to this process can be recorded and tracked in the Hudson Wiki. When commenting, please be sure to refer to the reference number of the section or paragraph that you have the comment on.
Older versions of this document are archived for inspection in the WWW source control area
The proposed Hudson release plan is that we should aim to release a new version of Hudson on a regular cycle of 5 weeks. This schedule will consist of a 4 week development sprint followed by a week of feature QA followed by a further week of integration and install QA.
We have attempted to capture the flow of this process in the following diagram, as you can see the individual iterations overlap by 1 week to provide the 5 week cycle.
Much of what is shown in this release process will be automated in the long term, however at this time activities such as changelog updates and staging of downloads are manual tasks to be handled by the various roles as defined within the Hudson community.
Hudson release planning occurs at the start of each new release phase and runs parallel to the BugFixing phase of the previous release. During that week we will consider all issues in Jira based on their priority and vote count. In scope, this will include both bug fixes and enhancements. Once candidate issues are identified the following will happen:
The proposed cycle includes a provision for various types of testing:
Prior to every check in (responsibility of the individual developer):
Release Testing (Automated / QA initiated):
To test and validate Hudson, we will start to classify the plug-ins using a tiered system. This will consist of 3 levels of plug-ins and The qualification of plug-in falling into this level is up to the Hudson committee and strictly governed. The definition of the tiers are:
The full list of plug-ins and their associated tier level is defined here.
The process here assumes that the developer is already a Husdon Core committer (as discussed in the Software Process) and has already signed the OCA.
The main code repository for Hudson Core is at GitHub (https://github.com/hudson). When a developer wants to work on the source code either to implement a new feature or create a patch for an existing issue they should follow the following process:
Unlike Hudson core, the hudson website artifacts are managed in subversion for ease of interoperability with content management tools such as Dreamweaver. During normal operation the website will operate on a continuous release cycle with changes made directly on the trunk and published immediately (or at least nightly). The one exception to this will be in Week 6 of the main development release cycle when we will branch the website in order to prepare the correct links for the new downloads and change logs.
Upon successfully release this release branch will be merged back into the mainline.
Comments or feedback? Head over to the wiki.
$LastChangedDate: 2011-03-14 18:15:29 +0000 (Mon, 14 Mar 2011) $