Skip to end of metadata
Go to start of metadata
Development

Development is conducted in cycles, which for ArchivesSpace is a month-long sprint during which new features are implemented, bugs are fixed, and chores, such as updating part of the application stack, are completed.  There are nightly build of the application so the latest features are available for iterative testing by the Testing sub-team and Program Team performing a Quality Assurance role. Public test candidate releases are created after the completion of 3 sprints.

Tag internal release

The Lead Developer / Release Manager will create a new tag based on the appropriate commit in the development branch with the version number prefixed with the letter v. For example, for version 1.0.0, the version should be tagged as v1.0.0:

$ git tag v1.0.0

A "patch release" to address security issues should be specified by adding a hyphenated, incremental patch number (e.g. v1.0.0-1 for the first patch release).

Acceptance of features

To confirm that a story is accepted into a release, the Program Team in their Quality Assurance role must confirm it has successfully passed all tests including:

  • all automated tests must pass before proceeding, and code coverage must be maintained at least to be 89%
  • passing test by the Testing sub-team  
  • no unresolved bugs from period of community testing of release candidate

Features, bug fixes, and chores that must be made acceptable before proceeding with a release are identified in JIRA as "blockers".  

Update developer documentation

The Scrum Master should ensure that the gh-pages branch contains the most up-to-date version of the developer documentation (e.g. API docs, models, etc.) generated using YARD:

$ build/run doc:yard

Push changes to stable branch

Once an internal release is tagged and tested, the Lead Developer pushes the resulting commits for the codebase, the new tag, and the updated development documentation to the master branch in the archivesspace/archivesspace repository:

$ git pull # or git fetch --tags ; git merge [branch] $ git push --tags git@github.com:archivesspace/archivesspace.git v1.0.0~0:master $ git checkout gh-pages $ git push git@github.com:archivesspace/archivesspace.git gh-pages

Verify status of build

The automated test suite will run on the Travis-CI continuous integration environment to ensure that the build does not fail.  Failures in the build process need to be investigated and resolved before the release process proceeds.  

Build a new release

If the test suite passes in Travis-CI, the release manager will build the new version using the build_release script:

$ scripts/build_release v1.0.0 

Once the new release is built, the release manager will rename the file so it includes the version name:

$ mv archivesspace.zip archivesspace-v1.0.0.zip 

Upload release

The release manager will upload the release to the Releases page and add notes for the latest version.  Releases will be listed in descending chronological order with the most recent release at the top of the list.  

Announce release

Finally, the release manager will indicate the new release is ready for distribution, and the Community Support manager will announce its availability to the ArchivesSpace users group list, the ArchivesSpace members representative list, the ArchivesSpace Governance Board list, the SAA Collection Management Tools Roundtable list, and the SAA Archives and Archivists list.   

Public release candidates are accompanied with a new version of the application at http://test.archivesspace.org.  This version of the application serves as the basis for testing the contents of the current sprint.  Testers may also download a release candidate and install it locally for testing.

Public test candidates and final releases will be announced to to the following locations: ArchivesSpace website, ArchivesSpace Users Group list, ArchivesSpace Google Group, Archives list, and the SAA Collection Management Tools Roundtable list.

  • No labels