Page History
...
Note | ||
---|---|---|
| ||
These same steps are also covered in the Sonatype Maven Repository Usage Guide |
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.
Info | ||
---|---|---|
| ||
Note that the version numbering convention for Language Packs is always the same as the current DSpace release, with an additional |
Info | ||
---|---|---|
| ||
Language pack updates are not back-ported. If you are making a security release for an older branch of DSpace, there will be no language pack commits to release. Continue with Final Commits & Preparation, below. |
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 the Language Pack Module:
git clone git
@github.
com:DSpace/dspace-api-lang.git dspace-api-lang
cd dspace-api-lang
git checkout master
NOTE: always release language packs from the master branch -- we do not use a maintenance branch for language packs.
- Do a Dry Run:
mvn release:prepare -DdryRun=true
- 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
- Make sure to assign a version number of the format:
- Deploy Artifacts to Staging in Sonatype:
mvn release:perform
- Verify and Release Staged Artifacts in Sonatype (see instructions at link)
- 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
Info |
---|
NOTE: if you're skimming these instructions, you may be tempted to think you've already handled this step, because you have already released new language packs, as detailed above. If you think so, you probably have NOT yet completed the steps below. The steps below tell DSpace what version of language packs to use. The language packs you've released following the steps above won't ever get used if you don't do the steps below. This is an easy thing to miss. Don't. Just check, to be sure. |
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:
Code Block |
---|
<!-- 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
Info | ||
---|---|---|
| ||
On skimming these instructions, this might look like a small thing, but it is not. It is a big information management task. Ask for help in wrangling/verifying the license information, and, if at all possible, DO NOT leave this job for release day. |
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:
Code Block |
---|
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.
Info | ||
---|---|---|
| ||
Note that the version numbering convention for Language Packs is always the same as the current DSpace release, with an additional |
Info | ||
---|---|---|
| ||
Language pack updates are not back-ported. If you are making a security release for an older branch of DSpace, there will be no language pack commits to release. Continue with Final Commits & Preparation, below. |
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 the Language Pack Module:
git clone git
@github.
com:DSpace/dspace-api-lang.git dspace-api-lang
cd dspace-api-lang
git checkout master
NOTE: always release language packs from the master branch -- we do not use a maintenance branch for language packs.
- Do a Dry Run:
mvn release:prepare -DdryRun=true
- 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
- Make sure to assign a version number of the format:
- Deploy Artifacts to Staging in Sonatype:
mvn release:perform
- Verify and Release Staged Artifacts in Sonatype (see instructions at link)
- 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 | ||||
---|---|---|---|---|
|
Double Check Language Packs' Version Ranges
Info |
---|
NOTE: if you're skimming these instructions, you may be tempted to think you've already handled this step, because you have already released new language packs, as detailed above. If you think so, you probably have NOT yet completed the steps below. The steps below tell DSpace what version of language packs to use. The language packs you've released following the steps above won't ever get used if you don't do the steps below. This is an easy thing to miss. Don't. Just check, to be sure. |
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:
Code Block |
---|
<!-- 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 theurl
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 thatjiraissue
plugin to list the proper version number informationNote 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.
- You'll notice all the JIRA history is generated via the
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. |
Double Check Contents of all README (and similar) files in GitHub
Info | ||
---|---|---|
| ||
On skimming these instructions, this might look like a small thing, but it is not. It is a big information management task. Ask for help in wrangling/verifying the license information, and, if at all possible, DO NOT leave this job for release day. |
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:
Code Block |
---|
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!
...