Page History

...

Release DSpace Language Packs (I18N) Modules

Before performing an official release, you should see if the DSpace Language Packs (i18n modules) need an updated release.  The easiest way to check if they need to be released it by checking to see if any commits have occurred since the previous release (see below for links).  Please note that you can release these I18N Modules on the same day as the main DSpace release.  The DSpace parent pom.xml is now configured to also check Sonatype's Release Repository for any Maven artifacts (so you do NOT need to wait for the I18N modules to appear in Maven Central)

At the moment the i18n modules are maintained in two separate GitHub projects. There are currently two i18n modules you will need to release:

• dspace-api-lang   - Check if any new commits have occurred on 'dspace-api-lang' since the last release.
• dspace-xmlui-lang - Check if any new commits have occurred on 'dspace-xmlui-lang' since the last release.

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):

1. Checkout the Language Pack Module:
   
   1. git clone git@github.com:DSpace/dspace-api-lang.git dspace-api-lang

   2. cd dspace-api-lang
   3. git checkout master 

      NOTE: always release language packs from the master branch -- we do not use a maintenance branch for language packs.
2. Do a Dry Run: mvn release:prepare -DdryRun=true
3. Tag and Increment Version: mvn release:prepare -Dresume=false
   
   • Make sure to assign a version number of the format: [major].[minor].[sequence-number] (e.g. 5.0.0, 5.0.1, etc for 5.0 releases of language packs)
   • NOTE: The release process should suggest the correct version number by default
4. Deploy Artifacts to Staging in Sonatype: mvn release:perform
5. Verify and Release Staged Artifacts in Sonatype (see instructions at link)
6. Go back and run steps #1-5 above for the other language packs modules (dspace-xmlui-lang)

Once both Language Packs have been released, you can immediately perform the DSpace release. You do not need to wait for them to appear in Maven Central, as our DSpace parent pom.xml will find them in Sonatype's Release Repository immediately.

...

Double Check Language Packs' Version Ranges

Once the Language Packs are released, you will probably need to modify the DSpace root pom.xml (https://github.com/DSpace/DSpace/blob/master/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 3.0.0, but is less than version 4.0.0:

<!-- DSpace Localization Packages -->
<dependency>
   <groupId>org.dspace</groupId>
   <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>
</dependency>

Ensure Documentation is Updated Appropriately

Hopefully, you've already been talking with others about getting Documentation updated!

You should also double check that the following "main pages" are updated in the Documentation:

...

• NOTE: For minor 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.

...

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 GitHub. These files reside in [dspace-src]. If anything is out-of-date, make sure to update it and commit the proper changes before continuing.

Regenerate the LICENSES_THIRD_PARTY file

The "LICENSES_THIRD_PARTY" file is now autogenerated via a Maven command (using the codehaus license-maven-plugin). Simply run the following from your local source directory to re-generate this file:

mvn clean verify -Dthird.party.licenses=true

On completion, a new, updated version of the LICENSES_THIRD_PARTY file will be written to your source directory. Please double check this file or "git diff" it to see if the changes look reasonable. Here are some things to especially be on the lookout for:

• If any dependencies are listed with an "UNKNOWN" license, then that means that dependency failed to specify its OS License in their own Maven POM file. We will need to manually lookup the license for that project, and manually add it to our src/main/license/LICENSES_THIRD_PARTY.properties file which corrects all "UNKNOWN" licenses. Finally, rerun the command above to regenerate the new LICENSES_THIRD_PARTY based on this update.
• If any dependencies are listed under an INCOMPATIBLE License (GPL, AGPL, etc), then we need to take a closer look at that dependency.  It is possible that the dependency is dual-licensed and therefore may be listed multiple times in the generated LICENSES_THIRD_PARTY file. If so, that's fine. If not, we may need to remove that dependency prior to the release.
• If any Open Source Licenses are listed under multiple names (e.g. "BSD" vs. "BSD License" vs. "BSD licence"), then we may need to update our POM configurations for the codehaus license-maven-plugin to tell it to merge licenses of those names into one. Those configurations are in the Parent POM under the <licenseMerges> tag of this plugin: https://github.com/DSpace/DSpace/blob/master/pom.xml#L406

If the file was updated, commit it.

Release DSpace Language Packs (I18N) Modules

Before performing an official release, you should see if the DSpace Language Packs (i18n modules) need an updated release.  The easiest way to check if they need to be released it by checking to see if any commits have occurred since the previous release (see below for links).  Please note that you can release these I18N Modules on the same day as the main DSpace release.  The DSpace parent pom.xml is now configured to also check Sonatype's Release Repository for any Maven artifacts (so you do NOT need to wait for the I18N modules to appear in Maven Central)

At the moment the i18n modules are maintained in two separate GitHub projects. There are currently two i18n modules you will need to release:

• dspace-api-lang   - Check if any new commits have occurred on 'dspace-api-lang' since the last release.
• dspace-xmlui-lang - Check if any new commits have occurred on 'dspace-xmlui-lang' since the last release.

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):

1. Checkout the Language Pack Module:
   
   1. git clone git@github.com:DSpace/dspace-api-lang.git dspace-api-lang

   2. cd dspace-api-lang
   3. git checkout master 

      NOTE: always release language packs from the master branch -- we do not use a maintenance branch for language packs.
2. Do a Dry Run: mvn release:prepare -DdryRun=true
3. Tag and Increment Version: mvn release:prepare -Dresume=false
   
   • Make sure to assign a version number of the format: [major].[minor].[sequence-number] (e.g. 5.0.0, 5.0.1, etc for 5.0 releases of language packs)
   • NOTE: The release process should suggest the correct version number by default
4. Deploy Artifacts to Staging in Sonatype: mvn release:perform
5. Verify and Release Staged Artifacts in Sonatype (see instructions at link)
6. Go back and run steps #1-5 above for the other language packs modules (dspace-xmlui-lang)

Once both Language Packs have been released, you can immediately perform the DSpace release. You do not need to wait for them to appear in Maven Central, as our DSpace parent pom.xml will find them in Sonatype's Release Repository immediately.

Anchor
Final Commits & Preparation Final Commits & Preparation

Final Commits & Preparation

Double Check Language Packs' Version Ranges

Once the Language Packs are released, you will probably need to modify the DSpace root pom.xml (https://github.com/DSpace/DSpace/blob/master/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 3.0.0, but is less than version 4.0.0:

<!-- DSpace Localization Packages -->
<dependency>
   <groupId>org.dspace</groupId>
   <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>
</dependency>

Ensure Documentation is Updated Appropriately

Hopefully, you've already been talking with others about getting Documentation updated!

You should also double check that the following "main pages" are updated in the Documentation:

• Release Notes- Should contain a very basic overview of the Release. Make sure the Release number is updated here!
  
  • NOTE: For minor 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 copy the last version's page and update the version numbers. For example, copy the previous release's page, and change as follows:
  
  • You'll notice all the JIRA 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+%223.0%22 ..." If you look closely, you'll see the 'fixVersion' is set to "3.0" in that search string. All you should need to do is update that version number (and the plugin will now search for tickets closed for 4.0)

  • 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.

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

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 GitHub. These files reside in [dspace-src]. If anything is out-of-date, make sure to update it and commit the proper changes before continuing.

Regenerate the LICENSES_THIRD_PARTY file

The "LICENSES_THIRD_PARTY" file is now autogenerated via a Maven command (using the codehaus license-maven-plugin). Simply run the following from your local source directory to re-generate this file:

mvn clean verify -Dthird.party.licenses=true

On completion, a new, updated version of the LICENSES_THIRD_PARTY file will be written to your source directory. Please double check this file or "git diff" it to see if the changes look reasonable. Here are some things to especially be on the lookout for:

• If any dependencies are listed with an "UNKNOWN" license, then that means that dependency failed to specify its OS License in their own Maven POM file. We will need to manually lookup the license for that project, and manually add it to our src/main/license/LICENSES_THIRD_PARTY.properties file which corrects all "UNKNOWN" licenses. Finally, rerun the command above to regenerate the new LICENSES_THIRD_PARTY based on this update.
• If any dependencies are listed under an INCOMPATIBLE License (GPL, AGPL, etc), then we need to take a closer look at that dependency.  It is possible that the dependency is dual-licensed and therefore may be listed multiple times in the generated LICENSES_THIRD_PARTY file. If so, that's fine. If not, we may need to remove that dependency prior to the release.
• If any Open Source Licenses are listed under multiple names (e.g. "BSD" vs. "BSD License" vs. "BSD licence"), then we may need to update our POM configurations for the codehaus license-maven-plugin to tell it to merge licenses of those names into one. Those configurations are in the Parent POM under the <licenseMerges> tag of this plugin: https://github.com/DSpace/DSpace/blob/master/pom.xml#L406

  • 
    

Ensure you tag multiple releases in chronological order!

...