Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: documented the official announcement channels

...

Info
titleVersion Numbering Convention for Language Packs

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 3.0 were numbered as follows: 3.0.0, 3.0.1, etc.


Info
titleOlder Branches Do Not Update Language Packs

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

...

  • Add the new contributors to the list: DSpaceContributors
  • Coordinate Announcements with DuraSpace Staff:
    • You might send post draft announcements to a service such as https://gist.github.com/ and send out a call to committers for review.  When finalized, DSpace releases should be announced on the dspace-devel mailing list for reviewcommunity, dspace-devel and dspace-tech lists/groups.
    • 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:
  • Also, update the Documentation Wiki area! Specifically:
  • For major releases, create a new branch in GitHub for any upcoming bug-fix releases:
    • E.g., after the 3.0 release, we created a 3.x branch for any subsequent bug fix 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 commands similar to:

      Code Block
      languagebash
      git clone git@github.com:DSpace/DSpace.git branchit
      cd branchit
      git checkout -b dspace-3_x dspace-3.0
      git push --set-upstream origin dspace-3_x


    • Then, go back to your master checkout, and make sure to update its version numbers in the pom.xml files by running the following:

      Code Block
      git checkout master
      mvn release:update-versions -Dmirage2.on

      (Remember to enter in the next appropriate major version number. E.g. After releasing 3.0, master 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.
    • Push your verified changes back to GitHub.
    • 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 master.
  • 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).
  • Updates to GitHub:  Move any uncompleted PRs to the next DSpace version tag.
  • Find the number of contributors (helpful data for the announcement, you are drafting an announcement, right?): for bugfix releases, it's: git shortlog -ns branch_name_goes_here ^master | wc -l

...