...

As of 2012 (DSpace 3.0), DSpace has moved to a new release numbering scheme/format. Release numbers will now only consist of two numbers.

Wiki Markup*Release Numbering Scheme:* {{\[major\].\[minor\]}} (e.g. 3.0, 3.1, 3.2, 4.0)

• Major Releases: incrementing the first number ('major') will represent a new MAJOR release of DSpace. A major release may include any or all of the following: new features, system improvements, architectural changes, bug fixes. All major releases end in ".0", so "3.0", "4.0", and "5.0" would all represent major releases.
• Minor (Bug-Fix) Releases: incrementing the second number ('minor') will represent a new MINOR release of DSpace. A minor release will only include bug fixes to an existing major release. For example, "3.1" and "3.2" would represent two minor releases which only include bug fixes to the "3.0" major release..

...

Prerequisites

Verify Release Privileges

...

1. Write access to the DSpace GitHub repository hosted at https://github.com/DSpace/DSpace. (All Committers should already have this, obviously)
2. 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. (If you already have a Sonatype account, you can skip this step)
   • Ask a Committer with release privileges (e.g. a previous release manager) to request that your Sonatype account be given release privileges to the "org.dspace" GroupID. This request should be submitted 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. You should also have access to publish new releases to the "org.dspace" GroupID.
   • The full details of signing up and getting access to Sonatype are also posted online here: Sonatype Maven Repository Usage Guide
3. 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:
     unmigrated-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

...

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): WARNING: INSTRUCTIONS NEED UPDATE FOR GITHUB!

1. Checkout Language Pack Module: svn co https://scm.dspace.org/svn/repo/modules/dspace-api-lang/trunk dspace-api-lang
2. Do a Dry Run: mvn release:prepare -DdryRun=true
3. Tag and Increment Version: mvn release:prepare -Dresume=false
   • Wiki MarkupMake sure to assign a version number of the format: {{\[major\].\[minor\].\[sequence-number\]}} (e.g. 3.0.0, 3.0.1, etc for 3.0 releases of language packs)
4. Deploy Artifacts to Staging in Sonatype: mvn release:perform
5. Verify and Release Staged Artifacts in Sonatype (see instructions at link)

...

git clone git@github.com:DSpace/DSpace.git ~/dspace-release
git checkout master

Do a Dry Run

...

This step is not required, but performs a useful sanity check without committing any changes. From your clean, up-to-date copy of master/branch, run the following command (from {{\[dspace-src\]}}):

Code Block
mvn release:prepare -DdryRun=true

...

Create the Distribution Zips for SourceForge

...

The previous actions will have checked out the release tag into the target directory under {{\[dspace-src\]/target/checkout}}. Navigate to that directory and execute the creation of the distributions using the following command. This will create two zip, bzip and gzipped files in the target directory. One set of files is the "binary" release, and the other set is the source release.

(Note: If you've already removed the target/checkout directory, you can also checkout a fresh copy of the newly tagged version and run this command from the DSpace parent directory.)

...

FATAL ERROR: "Reason: Could not find the model file '../dspace-api-lang'. for project unknown"unmigrated-wiki-markup

This is a known bug in Maven. The problem is that you likely have a 'dspace-xmlui-lang' or 'dspace-api-lang' folder at the same level as your \ [dspace-source\] parent folder. Essentially, Maven located them and tried to add them into the build process (which it shouldn't have). The fix is to completely delete the 'dspace-xmlui-lang' and 'dspace-api-lang' folders, and try to rebuild DSpace.