Page History
...
Info | ||
---|---|---|
| ||
For lack of a better place at this time, here's some useful pages on Sonatype: |
Prerequisites
...
Release
...
Numbering Convention
major.minor.subminor (e.g. 1.6.0)
- Increment subminor for bug-fix only releases (database, translations and core APIs stable)
- Increment minor for feature changes (database schema, translations, APIs may change, though we'll try and keep API changes as small as possible, and will always provide an upgrade/migration path)
The one exception is that the Language Packs (dspace-api-lang
and dspace-xmlui-lang
) use the numbering convention major.minor.subminor.sequence-number (e.g. 1.6.0.0). This allows us to release new versions of the language packs more frequently than normal DSpace releases.
Prerequisites
Verify Release Privileges
To perform a release, you must have all of the following:
- Write access to the DSpace subversion repository hosted at http://scm.dspace.org/svn/repo; This requires an administrator to add you to the svn repository permissions via the TRAC user group.
- Write access to the org.dspace groupId in the snapshot and staging repositories hosted at oss.sonatype.org. If you don't already have this, you will need to:
- Sign up for a Sonatype JIRA account. This account will also serve as your login to the Sonatype OSS system
- Ask the previous release manager to request authorization for this account via the Sonatype JIRA system in the Open Source Project Repository Hosting project. Once Sonatype gives you the proper authorization, you should be able to login to the Sonatype OSS system using the same login/password you setup in Sonatype JIRA.
- The full details of signing up and getting access to Sonatype are also posted online here: Sonatype Maven Repository Usage Guide
- You must generate and publish your own personal Code Signing Key (required by Sonatype). Here are two sites that give hints on how to do that:
- Creating a Code Signing Key
- How to Generate PGP Signatures with Maven (required for all Sonatype releases)
- Make sure to publish your Key file to
hkp://pgp.mit.edu
, as this is the Key Server Sonatype uses for verification:Wiki Markup (e.g.) {{gpg --keyserver hkp://pgp.mit.edu --send-keys \[yourKeyID\]}}
- You can see if your key is already on that Key Server by visiting http://pgp.mit.edu and searching on your name
- Write access to projects.dspace.org (which is where the DSpace Projects website is hosted)
- Ask the
To perform a release, you must have all of the following:
- Write access to the DSpace subversion repository hosted at http://scm.dspace.org/svn/repo; This requires an administrator to add you to the svn repository permissions via the TRAC user group.
- Write access to the org.dspace groupId in the snapshot and staging repositories hosted at oss.sonatype.org. If you don't already have this, you will need to:
- Sign up for a Sonatype JIRA account. This account will also serve as your login to the Sonatype OSS system
- Ask the previous release manager to request authorization for this account via the Sonatype JIRA system in the Open Source Project Repository Hosting project. Once Sonatype gives you the proper authorization, you should be able to login to the Sonatype OSS system using the same login/password you setup in Sonatype JIRA.
- The full details of signing up and getting access to Sonatype are also posted online here: Sonatype Maven Repository Usage Guide
- You must generate and publish your own personal Code Signing Key (required by Sonatype). Here are two sites that give hints on how to do that:
- Creating a Code Signing Key
- How to Generate PGP Signatures with Maven (required for all Sonatype releases)
- Make sure to publish your Key file to
hkp://pgp.mit.edu
, as this is the Key Server Sonatype uses for verification:Wiki Markup (e.g.) {{gpg --keyserver hkp://pgp.mit.edu --send-keys \[yourKeyID\]}}
- You can see if your key is already on that Key Server by visiting http://pgp.mit.edu and searching on your name
- Write access to projects.dspace.org (which is where the DSpace Projects website is hosted)
- Ask the previous release manager (or someone else with access) to be given access to this server.
- Include your proposed username
- Include a local SSH Public Key (which will be used for authentication).
...
For more information see the Pre-Requisities section of theSonatype Maven Repository Usage Guide
Making a Snapshot Release (e.g. 'dspace-
...
x.
...
y.
...
z-SNAPSHOT')
One Step Process
From a clean, up-to-date copy of trunk, run the following command:
...
You will have to enter in your GPG passphrase (which you established when you created your Code Signing Key).
The snapshot will be immediately available in the public Sonatype repository: http://oss.sonatype.org/content/groups/public
Making an Official Release (e.g. 'dspace-1.7.0' or 'dspace-1.7.0-rc1')
...
title | For More Information |
---|
when you created your Code Signing Key).
The snapshot will be immediately available in the public Sonatype repository: http://oss.sonatype.org/content/groups/public
Making an Official Release (e.g. 'dspace-x.y.z' or 'dspace-x.y.z-rc1')
Note | ||
---|---|---|
| ||
These same steps are also covered in the Sonatype Maven Repository Usage Guide |
Release DSpace Language Packs (I18N)
If possible, you should release the DSpace Language Packs (i18n modules) before the main release. Oftentimes, it's best to release these one or two days prior to the DSpace release (that way they've already propagated out to the Maven repository).
At the moment the i18n modules are maintained in SVN under the modules
folder:
http://scm.dspace.org/svn/repo/modules/
There are currently two i18n modules you will need to release:
dspace-api-lang
dspace-xmlui-lang
Note that the version numbering convention for Language Packs is always the same as the current DSpace release, with an additional .<sequence-number> (e.g. the i18n modules for the 1.6.0 release are numbered as follows: 1.6.0.0, 1.6.0.1, etc.)
For each module, perform the full release steps that follow. To save space, the steps are only listed for one of the modules (but don't forget to run it for both language packs):
- Checkout Module:
svn co https://scm.dspace.org/svn/repo/modules/dspace-api-lang/trunk dspace-api-lang
- Do a Dry Run:
mvn release:prepare -DdryRun=true
- Tag and Increment Version:
mvn release:prepare -Dresume=false
- Deploy Artifacts to Staging:
mvn release:perform
- Verify and Release Staged Artifacts (see instructions at link)
Final Commits & Preparation
Double Check Language Packs' Version Ranges
Once the Language Packs are released, you may need to modify the DSpace Parent pom.xml (http://scm.dspace.org/svn/repo/dspace/trunk/pom.xml) to reference the new version of the Language Packs. This should be similar to the following:
If possible, you'd only want to commit this after the i18n modules are available in the Maven Repository. But, if you are in a rush, you can commit this change earlier (though be warned that this will break the build process for anyone who hasn't manually installed the i18n modules to his/her local ~/.m2/
directory).
In the main pom.xml, provide the proper version range for each language pack. In the below example, we are saying to use any language pack version which is at least version 1.6.0.0, but is less than version 1.7.0.0:
Code Block |
---|
<dependency>
<groupId>org.dspace</groupId>
<artifactId>dspace-api-lang</artifactId>
<version>[1.6.0.0,1.7.0.0)</version>
</dependency>
<dependency>
<groupId>org.dspace</groupId>
<artifactId>dspace-xmlui-lang</artifactId>
<version>[1.6.0.0,1.7.0.0)</version>
<type>war</type>
</dependency>
|
Ensure HTML & PDF versions of Documentation is Committed
Double check that the latest Wiki-based Documentation has been exported as HTML and PDF and committed to http://scm.dspace.org/svn/repo/dspace/trunk/dspace/docs/
...
Do a Dry Run
This step is not required, but performs a useful sanity check without committing any changes. From a clean, up-to-date copy of trunk, run the following command:
...