ArchivesSpace re-org and committer groups proposal
How to Report a Bug
How to Request a New Feature
How to Contribute Code or Documentation
How to Participate in Community Release Testing (forthcoming)
Creating User Screencasts
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.
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
$ 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).
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:
Features, bug fixes, and chores that must be made acceptable before proceeding with a release are identified in JIRA as "blockers".
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
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
$ git pull # or git fetch --tags ; git merge [branch] $ git push --tags email@example.com:archivesspace/archivesspace.git v1.0.0~0:master $ git checkout gh-pages $ git push firstname.lastname@example.org:archivesspace/archivesspace.git gh-pages
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.
If the test suite passes in Travis-CI, the release manager will build the new version using the
$ 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
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.
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.