https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/RELENG-60 releng <p>As it stands there is no good way for a project to release outside of a simultaneous release. Going forward, we should provide tools (JJB templates?) to complete a release and publish it to a staging repository where it can be promoted to actually released (by LF staff or should projects have that permission too?). Also, we need to have tools or very good documentation to explain how to then do reasonable version bumps to prevent conflicts in SNAPSHOT repos on nexus.</p> <p>As part of that, release jobs (and autorelease) should produce csv files of all released artifacts with groupId, artifactId, and version which can be used for projects to target that (auto)release job's run for their dependencies.</p> <p>Beyond that, we probably also want tools to allow for a project to target a set of (auto)release jobs output as their dependencies. This should allow for a project to become "compatible with" a given release after the fact. For example to be compatible with a run of autorelease despite not participating in that simultaneous release.</p> <p>This last part probably amounts to a tool that takes a list of csv files and the replaces any versions for those artifacts in pom.xml and features.xml files in a subdirectory with those in the csv files and then makes sure that the only SNAPHSHOT version files are for the right groupId.</p> <p>Operating System: All<br/> Platform: All</p> RELENG-60

Provide tools and documentation to allow projects to release outside a simultaneous release

Bug Closed Done Thanh Ha (zxiiro) Colin Dixon Thu, 15 Jun 2017 13:46:41 +0000 Mon, 4 Nov 2019 14:12:45 +0000 Mon, 4 Nov 2019 14:12:45 +0000 unspecified Autorelease 0 5 <p>General plan from notes at the Nitrogen DDF:</p> <p>1.) Make autorelease produce at versions.csv file<br/> 2.) You need a script which takes the csv file and replaces all &lt;version&gt; tags with the right one from lookup in csv</p> <ul> <li>Is it enough to just look for &lt;artifactId&gt; and &lt;groupId&gt; and &lt;version&gt; at the same level, replace the version</li> <li>Optionally ignore your own groupId and subtree</li> <li>Optionally sanity check of things that are still SNAPSHOT are only your own groupIds<br/> 3.) Have a release job which removes your -SNAPSHOT and then publishes to staging repo</li> <li>Optionally publish a new versions.csv file for this release</li> <li>Copy most config and things from autorelease<br/> 4.) Bump versions and set back snapshot<br/> 5.) Who promotes the staging repository?</li> <li>Could the PTL get the permissions</li> <li>Do we want two release repos: one for Simultaneous Release another for off-cycle release<br/> 6.) Instructions for repo:add and feature:install<br/> 7.) Do we allow CSIT for projects that require repo:add? Add that command to robot?</li> </ul> <p>Note, 3-4 might be be handled by the maven release plugin.</p> <p>(In reply to Colin Dixon from comment #1)</p> <p>1) Is now possible due to <a href="https://git.opendaylight.org/gerrit/58124" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/58124</a></p> <p>2) Still needs to be built.</p> <p>3 &amp; 4) Is handled by `lftools version` script although it does not differentiate between groupIds although in theory if you're dependencies are already released then you shouldn't have any SNAPSHOTS outside of your own project anyway.</p> <p>5) Currently only HelpDesk can handle it however we will need to engage with LFIT if they'd be willing to allow project committers to promote their own staging repos.</p> <p>6 &amp; 7) I'm not sure about.</p> <p>LF has released a set of global-jjb jobs which makes this possible now.</p> Development External issue ID 8698 External issue URL Issue Type Rank 0|i01mav: