How Islandora Code gets Made

Contributing to Islandora

Islandora is committed to being a great open source project and to help improve that we are introducing new policies to improve our transparency. Communication is key to any successful project and we want to make sure the community is able to contribute in all discussions.

All new features should be discussed openly in [jira] (http://jira.duraspace.org/browse/ISLANDORA) please create a feature ticket for discussion giving the full community the opportunity to make recommendations and contribute to the development. The feature will then be broken down into tasks that will be managed by jira tickets. Bugs will simply be represented as a bug ticket in the jira system.

Code Repository

Github supports repositories for the Islandora and the DGI code repositories. Islandora is considered to be the master repository and is co-maintained by UPEI/DGI, and the DGI repository is a downstream repository that is maintained by DGI. We are moving to a new system of governance with the Islandora Foundation and information here may not always be up to date.

For code to be accepted into the master Islandora repository, a developer must publish the code in a forked repository and make a pull request. After the code has been reviewed and signed off then the code will be merged into the project. We use Travis for unittesting and Jenkins for integration testing/docs. Tests do not supply 100% coverage and Jenkins is currently unreliable so smoke testing of all pulls by reviewers is advisable. It is also advisable to run the tests and style checks on a module that is being altered before submitting a pull request. The command Travis runs for style checking in Drupal 7:

• drush coder-review --reviews=production,security,style,i18n,potx,sniffer module_name

Currently users with permissions may commit to repos dev branches as required, but only Component Managers should merge into release branches.

Questions about participating in the Islandora project can be directed to islandora-dev@googlegroups.com.

Releases

The release manager will set a code freeze date and time. No new features will go into the release. The only new code will be bug and issues fixes.

Prior to the code freeze, the release manager can create a release branch, or this can wait until the freeze.

At the point of the freeze the release manger will:

• Create and push a release branch

$ git pull 7.x
$ git checkout -b 7.x-1.3
$ git push origin 7.x-1.3

• If a release branch was created prior, then the development branch will need to be merged

$ git pull origin 7.x
$ git checkout 7.x-1.3
$ git merge 7.x

• *.info files will need to be updated to the current version

-version = 7.x-dev
+version = 7.x-1.3

This can be done with a find and replace via grep, but be very careful! grep -rl "version = 7.x-dev" | sed -i 's#version = 7.x-dev#version = 7.x-1.3#g'

• Commit and push to release branch

$ git commit -m "Version bump for 7.x-1.3" *.info
$ git push origin 7.x-1.3

• Create a release candidate

$ git tag -a 7.x-1.3-RC1 -m 'Islandora 7.x-1.3-RC1' 
$ git push --tags

After the release candidate is shared with the community, the focus will turn toward bug and issues fixes. Bug and issues fixes will need to go into both the development branch and release branch. To make things simple with our 40 or so modules, we will require pull requests for both the development branch, and the release branch. An example of this in action can be viewed here. In addition, with the establishment of Component Managers for releases, Component Managers should merge into release branches.

Release branch pull requests

The pull request process will roughly look like this:

1. fork from Islandora repo if that has not already been done
2. git remote add islandora git@github.com:Islandora/islandora_checksum.git
3. git pull islandora 7.x
4. Make changes, commit
5. git push origin 7.x and issue a pull request on 7.x
6. git fetch --all
7. git checkout 7.x-1.4 if that does not work, git checkout islandora/7.x-1.4 then git checkout -b 7.x-1.4
8. Make changes/cherry pick/copy changes from earlier, commit
9. git push origin 7.x-1.4 and issue a pull request on 7.x-1.4