...

Write access to the DSpace subversion GitHub repository hosted at httphttps://scmgithub.dspace.orgcom/svn/repo; This requires an administrator to add you to the svn repository permissions via the TRAC user group.DSpace/DSpace. (All Committers should already have this, obviously)
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

From a clean, up-to-date copy of trunkmaster/branch, run the following command:

...

The snapshot will be immediately available in the public Sonatype repository: http://oss.sonatype.org/content/groups/public

Releasing a Single Module

...

/Project

If you'd like to release a Snapshot Release of that module, follow the instructions at: Making a Snapshot Release (e.g. 'dspace-x.y.z-SNAPSHOT')
If you'd like to tag & release a new version of that module, use the module instructions at: Release DSpace Language Packs (I18N) Modules (NOTE: These instructions obviously have some specific notes around how the Language Packs modules are versioned. You obviously don't need to follow those versioning notes. Individual modules may have their own version schemes)

...

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 two separate GitHub projects. There are currently two i18n modules you will need to release:

Info

title	Version Numbering Convention for Language Packs

Wiki Markup

Note that the version numbering convention for Language Packs is always the same as the current DSpace release, with an additional {{.\[sequence-number\]}}. For example, the i18n modules for the 1.8.0 release are numbered as follows: 1.8.0.0, 1.8.0.1, etc.  However, for 3.0, the i18n modules will be numbered as follows: 3.0.0, 3.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): WARNING: INSTRUCTIONS NEED UPDATE FOR GITHUB!

Checkout Language Pack 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

Wiki Markup
Make 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)

Deploy Artifacts to Staging in Sonatype: mvn release:perform
Verify and Release Staged Artifacts in Sonatype (see instructions at link)

...

Once the Language Packs are released, you may need to modify the DSpace Parent root pom.xml (httphttps://scmgithub.dspace.orgcom/svnDSpace/repoDSpace/dspaceblob/trunkmaster/pom.xml) to reference the new version of the Language Packs. This should be similar to the following:

...

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 3.0.0, but is less than version 4.0.0:

Code Block

<dependency>
     <!-- DSpace Localization Packages -->
<dependency>
        <groupId>org.dspace</groupId>
   <artifactId>dspace-api-lang</artifactId>
          <artifactId>dspace-api-lang</artifactId>
             <version>[3.0.0,4.0.0)</version>
        </dependency>
        <dependency>
             <groupId>org.dspace</groupId>
             <artifactId>dspace-xmlui-lang</artifactId>
             <version>[3.0.0,4.0.0)</version>
             <type>war</type>
        <type>war</type>
</dependency>

Ensure Documentation is Updated Appropriately

...

Preface - Should contain a very basic overview of the Release. Make sure the Release number is updated here!
- NOTE: For Subminor releases (bug-fix-only releases), you may want to leave all information about the previous major release, and just enhance the content to state that this was a bug-fix release, and list any new contributors, etc.
Installation - Obviously make sure the Installation Documentation is updated for this Release
Upgrading a DSpace Installation - Same for the Upgrade Documentation, make sure it's up to date

History - Make sure the online History for this latest Release is included. You should be able to just edit the page, copy the fancy code that generated the history for another release, and update the version numbers. For example, copy the previous release's History section and change the release numbers as follows:

You'll notice all the release History is generated via the jiraissue plugin. In the url argument for that plugin, you should find the DSpace version number embedded in the querystring like: "... AND+fixVersion+%3D+%221.7.0%22 ..." If you look closely, you'll see the 'fixVersion' is set to "1.7.0" in that search string. All you should need to do is update that version number!

Also make sure to update the title argument for that jiraissue plugin to list the proper version number information

Note
Obviously, this is just a brief reminder of important areas of Documentation which always require updates. There's surely other areas, like Configuration section, which will require some updates for your release.

Ensure PDF version of Wiki Documentation is in

...

GitHub

Make sure the latest Wiki-based Documentation has been exported as PDF and committed to [dspace-src]/dspace/docs/ in SVNGitHub.

Info

title	How to Generate PDF Documentation

See this DSpace documentation management guide: How To Export Downloadable Docs from Wiki

Double Check Contents of all README (and similar) files in

...

GitHub

Make sure that the contents of all README, LICENSE, LICENSES_THIRD_PARTY, NOTICE files are up-to-date in SVNGitHub. These files reside in [dspace-src]. If anything is out-of-date, make sure to update it and commit the proper changes before continuing.

...

and commit the proper changes before continuing.

Pay close attention to the "LICENSES_THIRD_PARTY" file. You should attempt to determine if any third-party dependencies were added or removed and update their licensing information in this file. Information on the Maven commands that may come in handy when updating this file can be found in the Notes at the end of the "LICENSES_THIRD_PARTY" file.

Checkout Master or Branch to Release

Checkout a copy of the to-be-release version either from a branch or trunkmaster. For example:

Code Block
svngit coclone httpsgit@github.com:DSpace//scm.dspace.org/svn/repo/dspace/trunk DSpace.git ~/dspace-release git checkout master

Do a Dry Run

Wiki Markup

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

...

This step will set the version declared in the project's pom.xml files, commit the changes to trunkmaster/branch, tag the release, and finally, check in the trunkmaster/branch change that increments the next development version (e.g. x.y.z-SNAPSHOT) in the pom.xml files.

...

(Optionally, you may also include the parameters -Dusername=YourSVNUsername YourGitHubUsername -Dpassword=YourSVNPasswordYourGitHubPassword at the end of the above command, though I've not found these to be necessary)

...

Note

title	Backing out of changes

If backing out of this step is needed for any reason, the following will restore the subversion github repository and your working copy to the state it was previously in:

mvn release:rollback:rollback
Now delete the tag in GitHub (local & remote)
- git tag -d dspace-x.y
- git push origin :refs
svn rm https://scm.dspace.org/svn/repo/dspace
- /tags/dspace-x.y

Deploy Artifacts to Staging in Sonatype

...

Login to http://oss.sonatype.org/
Click "Staging Repositories" in the left column, then select the checkbox next to the staged repository on the right. The contents of it will open up at the bottom of the page.
With the staged repository still selected, click the "Close" button at the top.

Download and test that the artifacts in staging are exactly as they should be once deployed to central.

Info

title	If You Need to Revert Back before Releasing

If anything is incorrect, select the staged repository and select "Drop". After the problem is resolved, you can re-deploy the artifacts to staging and verify them again. To re-deploy an already-tagged release:
mvn release:perform -Dtag=dspace-x.y -DconnectionUrl=scm:svngit:httpsgit@github.com:DSpace//scm.dspace.org/svn/repo/dspaceDSpace.git -Darguments="-Dgpg.keyname=YourKeyId -Dgpg.passphrase=YourKeyPassword"

If everything looks good, select the repository and select "Release". The artifacts should be synced to Maven central (http://repo2.maven.org/maven2/org/dspace/) within an hour.

Warning

title	Once Released, There is No "Undo" Option

Once you select "Release", there is no way to "undo" the release. If any major issues are found, you'll have to increment the version number and perform a new bug-fix release.

...

Using scp to copy to the "DSpace Stable" file directory: (example for 1.8.0 final)
(NOTE: You will need to first create the 'DSpace Stable/1.78.0' directory via SourceForge's Admin UI)

...

Using scp to copy to the "DSpace Release Candidate" file directory: (example for 1.8.0-rc2)
(NOTE: You will need to first create the 'DSpace Release Candidate/1.78.0-rc2' directory via SourceForge's Admin UI)

...

Add the new contributors to the list: DSpaceContributors
Coordinate Announcements with DuraSpace Staff:
- Announcement on dspace.org, duraspace.org, twitter
- Ensure that the Latest Release page on dspace.org is updated.
  - Plus, ask dspace.org admins to upload latest documentation in PDF/HTML format
- Announce on all DSpace mailing lists
- Link announcement on Home of DSpace Wiki, change any version numbers listed on that page.
Update Wiki pages, particularly these pages which refer to the Current and Next Releases:
- CurrentRelease
- Next Release Status
- RoadMap
- NOTE: See DSpace Wiki Style Guide for notes on how to actually edit the above Redirect pages
Also, update the Documentation Wiki area! Specifically:
- All Documentation page -> Has current release info
- Homepage for the current Documentation (e.g. DSpace 1.8 Documentation) -> Has links to download latest version of DSpace
For major releases, create a new branch in SVN GitHub for any upcoming subbug-minor fix releases: (NOTE: BRANCH INSTRUCTIONS NEED UPDATE FOR GITHUB!)
- E.g., after 1.8.0 release, we created a 1.8.x branch for the subsequent 1.8.1 and 1.8.2 releases
- To automatically create a branch, you may be able to use the release:branch command (NOTE: untested, but it should work! once we test it out, this may be the best practice way of creating a branch).
- To manually create a branch, run a command similar to:
  Code Block
  svn copy http://scm.dspace.org/svn/repo/dspace/trunk \ http://scm.dspace.org/svn/repo/dspace/branches/dspace-3_x \ -m "Creating a branch for 3.x bug-fix releases."
  - Then, go back to your Trunk checkout, and make sure to update it's its version numbers in the pom.xml files by running the following:
    Code Block
    mvn release:update-versions
    (Remember to enter in the next appropriate major version number. E.g. After releasing 3.0, Trunk should be updated to "4.0-SNAPSHOT", while the new 3_x branch should be at "3.1-SNAPSHOT")
    - NOTE: the update-versions command doesn't always work perfectly. You will want to try a complete rebuild of DSpace before committing anything, as it sometimes misses updating a few version numbers.
  - You'll also need to ensure that all version numbers and the <scm> section is appropriate in the pom.xml files of your new Branch. Remember, the <scm> configurations should point at the branch, rather than back at Trunk.
For major releases, make sure to create a new DuraSpace Bamboo Project to auto-build the new branch you created in SVNGitHub.
- Usually, it's easiest to just 'clone' the existing Trunk project, rather than starting from scratch.
- You'll want to name it something similar to "18BRANCH" (for 1.8.x branch).
Updates to JIRA:
- Move any uncompleted issues to the next DSpace version tag in JIRA.
- Ask a JIRA Administrator to close out the release in JIRA (this will ensure no new issues can be added to that release).

...

Page tree

Versions Compared

Old Version 86

New Version 87

Key

Releasing a Single Module

/Project

Ensure Documentation is Updated Appropriately

Ensure PDF version of Wiki Documentation is in

GitHub

Double Check Contents of all README (and similar) files in

GitHub

Checkout Master or Branch to Release

Do a Dry Run

Deploy Artifacts to Staging in Sonatype

Page tree

Page History

Versions Compared

Old Version 86

New Version 87

Key

Releasing a Single Module

/Project

Ensure Documentation is Updated Appropriately

Ensure PDF version of Wiki Documentation is in

GitHub

Double Check Contents of all README (and similar) files in

GitHub

Checkout Master or Branch to Release

Do a Dry Run

Deploy Artifacts to Staging in Sonatype