1. www.opendaylight.org Versioning and Automated Weekly Releases

2. www.opendaylight.org There are over 250 bundles carrying different versions in OpenDaylight Automated release process using maven release plugin does not work reliably because of the way current pom files are structured When it is time to release, lot of time is wasted fixing pom files manually which makes the release very error prone Current Challenges 2

3. www.opendaylight.org Create a top level root parent pom that is above all the projects Move all the common external dependencies, dependency management, versions, plugin management etc to this pom Have only one parent per project unless otherwise necessary Separate aggregator pom from the parent and each project defines it’s parent in /parent directory of the project Project level parent pom is used to override defaults which are otherwise derived from the root parent pom. All the submodule and interproject dependency versions must be specified as a property in the parent pom. Proposed Solution 3

4. www.opendaylight.org Each project should follow semantic versioning If for some reason bundle version needs to be different than the project parent version, it can be overridden but specify the version of the bundle as a property in the project parent pom. With this approach all the properties will be defined only in one pom and will be very easy to inspect if something were to go wrong. Schedule automated weekly release for each project participating in simultaneous release using maven versions plugin + maven release plugin + Jenkins Use consistent naming convention for git tags for all projects in simultaneous release Proposed Solution 4

5. www.opendaylight.org Few examples after restructuring 5 This is how properties section looks like in the project level parent.   0.5-SNAPSHOT  1.1-SNAPSHOT  0.8.1-SNAPSHOT  0.1.2-SNAPSHOT  0.2.5-SNAPSHOT  2.4.3  2.4.0  2.5  [0.6.0,)  1.0  As shown above, range has been specified for yang.tools.version, which will use the version equal or greater than 0.6.0. Or we can always specify “LATEST” that way during development, we are current always. During the release, it can be changed to a particular release version.

6. www.opendaylight.org Few examples after restructuring 6 Project level parent inheriting super parent and overriding the version: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> org.opendaylight.odl odl-root-parent 1.4.3-SNAPSHOT 4.0.0 yangtools-parent org.opendaylight.yangtools 0.6.2-SNAPSHOT pom

7. www.opendaylight.org Few examples after restructuring 7 Project level parent inheriting super parent and inheriting the version from the parent: 4.0.0 3.0 --> org.opendaylight.odl odl-root-parent 1.4.2-SNAPSHOT org.opendaylight.openflowplugin openflowplugin-parent pom

8. www.opendaylight.org Using Versions & Release Plugin 8 If we have a pom file specified something like this: 1.0-SNAPSHOT 1.1-SNAPSHOT and all modules use that like this: group dependency1 ${dependency1.version} From Jenkins execute  “mvn versions:update-properties”  “mvn release:prepare release:perform –B”

9. www.opendaylight.org After the pom files are re-structured and release automation is in place, there is a possibility that pom files can get into similar situation very quickly. To prevent this from happening, we can have a gerrit pre-commit gate that validates the pom files, if a pom file is part of the commit. If the pom file does not meet the criteria, jenkins verification build will fail for that particular project Future Considerations 9