Page History
...
- GitHub - The main codebase is now here. See Development with Git for some hints/tips.
- JIRA - Obviously this is where we log all bugs/tickets. It is also used to auto-generate the "History" page of our DSpace Documentation, e.g. 1.8 History page
- Bamboo - We use Atlassian Bamboo tool for automatic building/testing of any new commits to GitHub. If an error occurs during an automated build/test, then an email is set to the dspace-changelog listerv. More info at: ContinuousIntegration
- DSpace Wiki - The public wiki space. A few areas to be aware of (if you are not already)
- Committer Guidelines - Splash page for all our Committer Guidelines. We try to keep this as up-to-date as possible. But, if you have questions, please ask!
- Release Procedure - In case you are interested, this is our procedure for cutting a new release.
- DSpace Documentation - The official DSpace documentation is created in the wiki (and PDFs are generated from the wiki during releases). This is the splash page which lists all the existing DSpace Wiki Documentation.
- How we generally manage this Documentation is on a subpage: Documentation Management
- SourceForge - These days, SourceForge is primarily used for two purposes: (1) it hosts all of our mailing lists, and (2) we post all releases up there for download.
- demo.dspace.org - The demo installation of DSpace which is on a virtual server (Amazon EC2 w/Ubuntu Linux). This server is used to show off the latest version of DSpace, as well as to help test upcoming features during release Testathons.
- Any Committers can request command-line access to this server (to start/stop the instance, upgrade it, etc) by sending your Public SSH Key to Tim (or to any other Committer who already has command-line access to this server).
- www.dspace.org - Main website which is managed by DuraSpace. If you need something changed/updated there, contact Tim or email sysadmin at duraspace.org
...
Git/GitHub Intro
Regarding commits to SVNGitHub:
- As a new Committer, you obviously have full rights to commit code. Usually, we try to not commit major code to DSpace that has not be reviewed by others (by posting a patch to JIRA GitHub Pull Request and JIRA ticket for review). But, obviously minor bug fixes/typos can just be fixed immediately – there's no need to review things that are obvious.
- Please review to the Guidelines for Committing for additional hints/tips on our normal commit process.
- Also read Development with Git for some hints/tips on GitHub development practices
There are actually several areas of SVN projects in GitHub (in case you haven't browsed around it much). Here's a very brief overview of the main areas projects available off of httphttps://scmgithub.dspace.org/svn/repo/
| Code Block |
|---|
repo/
dspace/
trunk/ (absolute latest DSpace code -- this is where development for the *next* major version of DSpace happens)
branches/
dspace-1_6_x/ (latest 1.6.x code -- once a new major version is released, all minor/bug-fix versions are developed out of its branch)
tags/ (this is where official releases of the software are tagged, e.g. 1.6.0, 1.6.1, 1.6.2, etc.)
dspace2/ (This is the DSpace 2.0 prototype from 2009)
modules/ (Various Maven-enabled DSpace modules for both 1.x and 2.x)
sandbox/ (A sandbox where anyone can work on prototypes of DSpace changes/features)
tools/ (Maven management/assembly tools)
|
More information on the SVN hierarchy is also available off of our Modules wiki page.
...
- DSpace - The main codebase.
- The "master" branch is where development for the next major version of DSpace happens
- The various other branches (e.g. 'dspace-1_8_x') are "maintenance branches"
- The tags (e.g. 'dspace-1.8.0', 'dspace-1.8.1', 'dspace-1.8.2') are the official stable releases of the software
- dspace-solr - Special, slightly customized version of Solr, which is released separately to Maven Central (so DSpace can use it as a dependency & include it out-of-the-box)
- dspace-cocoon-servlet-service-impl - Patched version of Cocoon Servlet Service which resolves issues with Cocoon swallowing 404 Errors, which is released separately to Maven Central (so DSpace can use it as a dependency & include it out-of-the-box)
...
Also, 'dspace/branches' are generally used for bug fix releases (e.g. 1.6.1, 1.6.2, etc.). The 'dspace/trunk' is generally used for the next major release (e.g. 1.7, 1.8, etc.). Obviously, if something is a 1.6.0 bug fix, it should be committed both to 'branches/dspace-1_6_x/' and to 'trunk' so that the bug is fixed for both 1.6.1 and 1.7.
How to change your working copy so you can actually commit to SVN:
It is likely you already have a read-only checkout of dspace_trunk, if so, you can change that to a read/write checkout. From the command line, you can just type:
| Code Block |
|---|
cd [working copy]
svn switch --relocate http://scm.dspace.org/svn/repo/dspace/trunk https://scm.dspace.org/svn/repo/dspace/trunk
|
...
- dspace-geoip - Project that deploys MaxMind GeoIP releases (http://sourceforge.net/projects/geoip/
) to Maven Central for DSpace (so DSpace can use it as a dependency & include it out-of-the-box) - dspace-services - The DSpace Services Framework, which is released separately to Maven Central (so DSpace can use it as a dependency & include it out-of-the-box)
- dspace-api-lang - The DSpace API/JSPUI Language Packs, which are released separately to Maven Central (so DSpace can use it as a dependency & include it out-of-the-box)
- dspace-xmlui-lang - The DSpace XMLUI Language Packs, which are released separately to Maven Central (so DSpace can use it as a dependency & include it out-of-the-box)
IRC Overview
- If you can, try to join our DSpace Developer Meetings in #duraspace IRC. It's a good way to stay "in the loop". It's also a good way to get to know everyone. If you cannot make the meeting, transcripts are also available on the above wiki page and off of http://irclogs.duraspace.org/.
...
Overview
Content Tools