...
The ArchivesSpace development process is informed by the concept Agile software development. The ArchivesSpace codebase is continuously updated with new features and fixes for bugs reported by the user community. New releases appear often (typically once each quarter during three times a year), though it is not expected that system administrators will update their installation each time a release appears. At least four times a year In preparation for a release, the ArchivesSpace team will publicize a release and recommend that users upgrade to itusually puts out at least one release candidate and publicizes an opportunity to test it before the production release comes out.
The process is intended to be driven by use cases, feature requests, and bug reports contributed by ArchivesSpace users and processed into ticketed items in JIRA, our issue tracking system. At the beginning of each fortnightly "sprint" high priority issues are reviewed and distributed to the development team. At the end of the sprint the development team submits a "build" containing all the work the team (and outside code contributors) were able to do during the sprint. The build is then passed to the community for acceptance testing. Acceptance testers use the build in concert with the issue tracking system to work through all issues marked "delivered" and change their status to either "accepted" or "rejected". Rejected issues will be fed back into the sprint / build / test cycle.
Other Topics in this Section
...
Development is organized in sprints, with a set of issues distributed to participating developers at the beginning that are then reported out at the end. Issues may be delivered at any time during the sprint cycle. Some issues are completed in a single sprint, some over multiple sprints. As they are delivered, issues are tested by acceptance testers, who comment on them in JIRA. As the time of a release nears, additional testing takes place to ensure that there have not been any regressions.