100 likes | 115 Views
Versioning and Automated Weekly Releases. Current Challenges. 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
E N D
Current Challenges • 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 – Few Examples • 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
Proposed Solution • 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 • 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
Future Considerations • 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