Skip to end of metadata
Go to start of metadata
When will new functionality or bug fixes be available?

All ArchivesSpace code is developed in the open, by multiple developers and the ArchivesSpace Program Team. Development runs on a time-based release cycle.  

In 2016, new features will be released every four months, these are x.x.0 releases (1.4.0, etc). New feature releases are accompanied by a source code snapshot that the community can use as a basis for development work. 

Fixes for significant bugs classed as blockers are distributed in “maintenance” releases as  warranted; these are the x.x.x releases (1.4.2, etc). Other bugs fixed will be released as part of a features release.  Maintenance releases  are also accompanied by a development release.

How does code get into ArchivesSpace?

The development process is designed to facilitate engagement between the ArchivesSpace Program Team, ArchivesSpace community developers, and users of ArchivesSpace.

There are several groups involved in the ArchivesSpace development process:

The current process is:

  1. A bug or feature request is submitted by an ArchivesSpace user(s) or by the Program Team on a users’ behalf. These requests can be entered at any time. To speed up the process, requests should be thoroughly described.
  2. Initial evaluation of newly submitted requests is performed by the ArchivesSpace Program Team on a regular basis. The Program Team will ask the requester to provide further information to the issue if needed. For sufficiently described features, the Program Team checks if the feature and/or bug:
    • has already been reported
    • has already been addressed or is a feature already in the application
    • is institution-specific
  3. Move of requests to “icebox” in ArchivesSpace development queue. If a request is not a duplicate, describes new functionality and is generic rather than specific, the Program Team moves the issue to the the “icebox” in the ArchivesSpace development JIRA and assigns it a Epic label so it can be viewed alongside similar issues – e.g. ‘EAD export’, ‘container management’.
  4. Development prioritization. On at least a monthly basis, the Development Prioritization Team reviews and prioritizes according to established criteria all new issues without pre-assigned development resources, i.e. where an individual or organization has not already committed developer time to work on them. If a feature or bug is not adequately described to hand off to a developer, the developers may follow up with the requester for additional information.
  5. Open Scrum meeting to assign work.  On a monthly basis a virtual scrum meeting is held to assign development work for the upcoming, month-long sprint. Anyone in the community may join the call but only those willing to take on work assignments can participate. Required attendees include the ArchivesSpace Program developers, the Program Manager, Testing subteam lead (or representative) and Development Prioritization subteam lead (or representative).  Members of the documentation sub-teams are also encouraged to join in order to take on documentation work associated with new functionality. A more detailed description of this meeting is available here. 
  6. Development and testing. During weeks 1 – 3 of each month-long sprint, the Program Team and community developers work on code and documentation. As a developer completes a story, the work is handed off to a pre-assigned tester from the Testing sub-team. The Tester will be added as a watcher to tickets so they can be automatically notified when a features is ready to be tested.
  7. Quality assurance testing.  During the last week of each sprint, the Program Team performs final tests on all work delivered during the sprint. Based on the results of Q/A testing, the Program Team indicates which stories are accepted for the scheduled release and which are rejected.  Rejected stories may be resolved during the last week of the sprint, deferred to the next sprint, or placed into the backlog for a future release.
  8. Final testing and release. The designated Release Manager prepares a Release Candidate three-weeks in advance of the next release date. The ArchivesSpace Community Support Manager notifies the community of the presence of the release candidate, indicates new features and bug fixes in the release, and invites the community to test those additions as well as other areas of the application. Problems reported are cycled back to the Program Team for resolution.  Problems may be resolved prior to the release and included in it, or removed from the release and targeted for a later release.  The designated Release Manager prepares the release, after the community testing period is over and all resolutions made.  The Community Support Manager announces the distribution of the release, indicating the new features and bug fixes that made it into the release, as well as those that ultimately "fell out".

The ArchivesSpace community is always looking for ways to improve the development process. If you have any good ideas about improvements, please share them in comments below or by emailing ArchivesSpaceHome@lyrasis.org.



  • No labels