Skip to content

Latest commit

 

History

History
29 lines (27 loc) · 4.92 KB

ReleaseProcess.md

File metadata and controls

29 lines (27 loc) · 4.92 KB
Raw

JGraphT Release Process

  1. Let other developers on jgrapht-dev know that you're starting on the release and ask them to hold off on merging changes until the release is complete.
  2. Review the README.md, HISTORY.md, CONTRIBUTORS.md, and update:
    • Version
    • Dependencies
    • Release notes
    • Contributors
    • Copyright year
  3. Review/update github issues to make sure they reflect the current state. If there were important bug/feature changes, it is worth mentioning them in the README.md release notes.
  4. Run mvn clean; mvn javadoc:aggregate to build the javadoc and make sure it is generated without errors/warnings. Fix where necessary. Make sure Eclipse build is warning-free.
  5. Run all the JUnit tests via mvn test. Fix where necessary.
  6. Reformat all code using Eclipse.
  7. Commit all work and push to github, merge with master branch. Locally, switch back to the master branch and perform a git pull upstream master to ensure that the local and upstream master are synced after merging the code formatting changes.
  8. Run mvn -Dmaven.artifact.threads=1 -DskipTests clean deploy to push the latest snapshot to Sonatype.
  9. Run mvn package -DskipTests; mvn release:prepare; mvn release:perform to create the Maven artifacts and push them to Maven Central
  10. Publish the release using the Sonatype UI. Make sure to login to the old https://oss.sonatype.org/, and NOT https://s01.oss.sonatype.org/ or you will get a Incorrect username, password or no permission to use the Nexus User Interface. error!
  11. Before continuing, restart from a fresh clone to make sure your workspace is clean, and checkout the release branch there by performing a git checkout jgrapht-x.y.z. Otherwise, if you have old files lying around that are hidden by .gitignore, they may get accidentally included in the release archive.
  12. Run mvn javadoc:aggregate; mvn -DskipTests install from the new release branch to produce the release archive distribution
  13. Upload the release archive distribution to sourceforge using the File Release System.
  14. Add the javadocs for the new release to the javadoc repository. To do this, push a commit which replaces the contents of the existing javadoc directory, and also adds an identical copy under a new javadoc-x.y.z directory.
  15. Update the website with links to the new downloads, version numbers. Make sure you are on the master branch, NOT on the gh-pages branch! (To be specific, you'll need to update the Jumpstart, Download, and News sections.) which can be found under ./docs/_posts/. Be sure to push this commit after the javadoc update from the previous step; this will trigger an automatic rebuild of the website (the javadoc gets loaded automatically).
  16. Announce the new version in the mailing lists: [email protected], [email protected]
  17. Update and commit the version number in HISTORY.md to reflect the beginning of development for the next version. Finally, remove all existing deprecated methods.
  18. Check and, if necessary, update dependencies: mvn versions:display-dependency-updates. Recompile to check whether any of the version updates introduced errors, e.g. because some methods have been deprecated: mvn -Dmaven.compiler.showWarnings=true -Dmaven.compiler.showDeprecation=true clean compile. Then use mvn package to rebuild an archive distribution. Unpack an archive (either .zip or .tar.gz) under jgrapht-dist/target, and then inspect the contents of the unpacked jgrapht-x.y.z-SNAPSHOT/lib directory. Make sure that no unexpected transitive dependencies have crept in by comparing the jars with those from the release archive distribution (which you can download and unpack). If everything is OK, then submit the dependency updates as a pull request and wait for a reviewer to merge them. We perform dependency updates at the start of a new development cycle to give plenty of time for any incompatibilities to be noticed, but it's also OK to do this step in the middle of a long development cycle (or at any time as needed for specific dependencies, e.g. to take advantage of a new feature, or to close a security hole).

Notes

  • The release artifacts are signed with private keys. In order to sign this release, you'll need to make sure you've already created and published your own key.
  • To rebuild the full release package after it has been pushed to github, you can run git checkout jgrapht-x.y.z (the tag you published for the release), and then run mvn clean; mvn javadoc:aggregate; mvn package