Page Tree:

Child pages
  • Software Version Control Policy

This wiki space contains archival documentation of Project Bamboo, April 2008 - March 2013.

Skip to end of metadata
Go to start of metadata

Bamboo Technology Project Software Version Control Policy


(1) All institutions participating as partners in BTP Phase One signed an IP agreement with the Andrew W. Mellon Foundation. This agreement obligates us to "make available to the nonprofit educational, scholarly, and charitable communities all Software developed [...] pursuant to an Educational Community License, Version 2.0 [...]." (Quoted from IP agreement, Sec 1.)

(2) We are obligated to make software available "on a royalty-free, open source basis in an open source depository such as and/or the Bamboo Technology Project Web site, or office of technology transfer." (Quoted from IP agreement, Sec 2.)

(3) The "Coordinating Principles" articulated in our proposal to the Mellon Foundation describes "an active culture of [...] collaboration" and that we will "encourage communication and transparency." (Quoted from BTP proposal to the Mellon Foundation, Sec 6.6, p52.)

Stable point of publication of software

(4) While the IP agreement gives us latitude about where, when, and how software can be made available, this policy is articulated in relation both to the IP agreement and to our commitment to collaboration, communication and transparency. With these agreements and commitments in mind, this policy formalizes BTP practice to version and publish software artifacts of our project in a Bamboo-managed, Bamboo-domain code repository as a single point of publication for work-in-progress as well as a stable point of dissemination for our software source code.

(5) Single or stable point of publication [and] dissemination does not imply only point [...]. Any code Project Bamboo produces may be published and/or versioned elsewhere by a Project Bamboo Partner and/or an Area of Work team, in addition to being published and versioned in our common, Bamboo-domain repository.

(6) Berkeley, as Managing Partner, maintains a shared instance of Subversion (svn) as the BTP's common, stable, and single point of publication and dissemination.

Alternate, additional tools for version control and points of publication

(7) Institutions and/or teams who wish to do so are free to use use an alternate Version Control System (VCS) – such as git, mercurial, hosted git (github), etc. – bearing in mind that any cost of managing and using a different VCS cannot be supported by Mellon Foundation funds budgeted for servers and development tooling (these funds are managed by Berkeley in BTP Phase One).

(8) In addition, institutions and teams that choose to use an alternate VCS will be responsible to duplicate commits made to the alternate VCS with commits to the central, shared Subversion instance. This needs to be accomplished via automated mechanisms that assure synchronization without need for tiresome and easy to forget duplication of effort by the developer committing code. For example, this might be accomplished with git-svn in the case of git-hosted repositories, invoked as a post-receive or post-commit hook. On the Subversion side of this transaction, appropriate repositories or repository directories, as well as accounts, will be provided. The working assumption is that this will not be an onerous task on either side of the synchronization; if it is, institutions and teams are strongly encouraged to use only the provided Subversion repository.

Code committers and code commit frequency

(9) Committers to the centrally-managed BTP repository are limited to team members affiliated with or contracted by Partner institutions, in accordance with terms of our IP agreement with the Mellon Foundation (Sec 4); and who have been approved as committers by the concerned Area of Work lead(s).

(10) Frequency of commits should coincide with discrete units of developer activity. In an active development project, working developers should commit their code at least weekly, and likely more frequently. The purpose of comitting code is not just to share it; it is also to protect BTP & institutional investment in the developer's time & work by providing a centrally and professionally-managed backup mechanism. This suggested frequency is not intended to be a rule, let alone a hard-and-fast rule; but only to set expectations that BTP participants will commit code as it evolves, not only when it is judged complete, or ready-for-release. This gives each of us visibility into the nuts and bolts of ongoing work, which is consistent with our principles of collaboration, communication, and transparency; and facilitates project management at all levels of granularity. Hopefully, it will also allow us to correct course when each or any of us takes a direction that might pose integration problems down the road.

Applicability of policy and license

(11) This policy applies to any software that is written or adapted by persons who are paid from grant funds or cost-share (funds or effort) to the Mellon grant.

(12) Source code (software) to which this policy applies will include in its head (at the top of each source code file) the body or a link to Project Bamboo software license, which includes a brief header and the ECL 2.0 license. The Project Bamboo software license material will be published in the Project Bamboo code repository, at the URL, and may be referenced at that location. A draft of this license is included below.

Project Bamboo Software License

The Project Bamboo Software License is versioned and available at

  • No labels