Comment on page
How to conduct a release to Maven Central
Deeplearning4j has several steps to a release. Below is a brief outline with follow on descriptions.
- 1.Compile libnd4j for different cpu architectures
- 2.Ensure the current javacpp dependencies such as python, mkldnn, cuda, .. are up to date
- 3.Run all integration tests on core platforms (windows, mac, linux) with both cpu and gpu
- 4.Create a staging repository for testing using github actions running manually on each platform
- 5.Update the examples to be compatible with the latest release
- 6.Run the deeplearning4j-examples as a litmus tests on all platforms (including embedded)to sanity check platform specific numerical bugs using the staging repository
- 7.Double check any user related bugs to see if they should block a release
- 8.Hit release button
- 9.Perform follow up release of -platform projects under same version
- 10.Tag release
At the core of compiling from source for libnd4j is a maven pom.xml that is run as part of the overall build process that invokes our build script with various parameters that then get passed to our overall cmake structure for compilation. This script exists to formalize some of the required parameters for invokving cmake. Any developer is welcome to invoke cmake directly.
- Platform compatibilityWe currently compile libnd4j on ubuntu 16.04. This means glibc 2.23.For our cuda builds, we use gcc7.Users of older glibc versions may need to compile from source. For our standard release, we try to keep it reasonably old, but do not support end of lifedend of linux distributions for public builds.
- Platform specific helpers
This is a step that just ensures that the dl4j release matches the current state of the dependencies provided by javacpp on maven central. This affects every module including python4j, nd4j-native/cuda, datavec-image, among others. The versions of everything can be found in the top level deeplearning4j pom The general convention is library version followed by a - and the version of javacpp that that version uses.
Of note here is that certain older versions of libraries can use older javacpp versions. It is recommended that that the desired version be up to date if possible. Otherwise, if an older version of javacpp is the only version available, this is generally ok.
We run all of the major integration tests on the core major platforms where higher end compute is accessible. This is generally a bigger machine. It is expected that some builds can take up to 2 hours depending on the specs of the desired machine.
To ensure the examples stay compatible with the current release, we also tag the release version to be the latest version found on maven central. This step may also involve adding or removing examples for new or deprecated features respectivley.
- 1.Different supported cuda versions with and without cudnn
- 2.Onednn and associated classifiers per platform
Ensure testing happens on the android emulator.
The examples contain a set of tests which just allow us to run maven clean test on a small number of examples. Instead of us picking examples manually, we can just run mvn clean test on any platform we need by just specifying a version of dl4j to depend on and usually a staging repository
Generally, sometimes users will raise issues right before a release that can be critical. It is the sole discretion of the maintainers to ask the user to use snapshots or to wait for a follow on version. For certain fixes, we will publish quick bugfix releases. If your team has specific requirements on a release, please contact us on the community forums
After a release happens, a version update to the stable version + a github tag needs to happen. This is achived in the desktop app by going to: 1. History 2. Right click on target commit you want to tag 3. Click tag 4. Push the revision 5. Update the version back to snapshot after tag.