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 Multiple parent pom’s within a given module  For example, mdsal in controller project has 2 parents: sal- parent at version: 1.1-SNAPSHOT and compatibility parent which is also at 1.1-SNAPSHOT. Both of these parents are pointing to another parent which is at 1.4.2-SNAPSHOT. Bundle versions not derived from the parent  In UserManager pom file, the parent version is defined as 1.4.2-SNAPSHOT but the bundle version is 0.4.2-SNAPSHOT Cross project dependencies listed directly in the Bundle POM instead of deriving it from the parent Current Challenges – Few Examples 3

4. www.opendaylight.org Proposed Solution - Overview 4

5. www.opendaylight.org Have only one version per project/git repo Have only one parent per project unless otherwise necessary Define a global pom which is common to all the projects participating in simultaneous release This global pom will maintain the release version which could be $MAJOR.$MINOR-$BUILD_NUMBER All sub-project’s parents will inherit the global pom file Proposed Solution 5

6. www.opendaylight.org Project dependency versions have to be defined as properties in the parent pom and should not be hardcoded in the module pom’s 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 6

7. www.opendaylight.org Current Maven Dependency tree 7

8. www.opendaylight.org Future Maven Dependency tree 8

9. www.opendaylight.org Demo

10. 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 10