Date
1 - 2 of 2
[E] Re: [integration-dev] integration/distribution version issues
|
Sangwook Ha
Looking at the release & version bump cycle, some of the steps may be simplified, and hopefully automated: - For each release of managed projects, release & version bump, are done separately a few days apart - is there any reason why this cannot be done together? - For 'opendaylight/pom.xml' there are multiple manual steps: can steps 2 & 3 be merged & done automatically? 1) activate profiles for self-managed projects 2) release 3) update versions and deactivate profiles for self-managed projects (sometimes the version bump is done in two separate steps: the artifact/karaf & self-managed project) And there are two different types of release tags - one for managed projects (e.g. release/silicon-sr3) and common release (14.3.0). The former does not update 'opendaylight/pom.xml' but the latter updates all the POM files. And this is confusing because all the versions except for 'opendaylight/pom.xml' have been bumped up by the time the release is made, and they have a version ahead of what the label says (e.g. for the tag '14.3.0' all the versions except for 'opendaylight/pom.xml' is '14.4.0'). Thanks, Sangwook On Wed, Nov 17, 2021 at 1:18 AM Robert Varga <nite@...> wrote: On 17/11/2021 08:26, Luis Gomez wrote: |
|
|
|
Robert Varga
On 17/11/2021 17:42, Ha, Sangwook wrote:
Looking at the release & version bump cycle, some of the steps may be simplified, and hopefully automated:Yes there is and there is quite a bit of history attached to that. Our governance clearly states that each project is independent, which in this context means is free to release whenever as well as can decide to release outside of Simultaneous Release. During our initial (Hydrogen, 2014) release, we have had all projects integrating on SNAPSHOTs and the release party was ... not awesome. If you see git tags like "jenkins-controller-bulk-release-prepare-only-2-1", those are from that period. There were multiple technical reasons why it did not go so well. As a reaction to that, autorelease was created, to have all projects still integrated on SNAPSHOTs, but projects gave up their right to release on their own and instead all projects were release by LFN personnel in one large chunk -- we are still doing this for MSI projects. The experience of being integrated on SNAPSHOTs was ... not exactly great -- it lead to the creation of validate-autorelease and distribution-check jobs, which gate every patch so that it does not happen to break downstreams. We have mostly addressed the technical issues by 2017 and started peeling projects away from autorelease with odlparent-2.0.0 (IIRC). Fast forward to today and autorelease does not carry a single kernel project. With that context, I will never agree to going for "release together" -- that amounts to autorelease hell. I have endured it for years upon years and have toiled sweat and blood to get out of it. I am *NEVER* going back to that, period. Can we do better than we are doing today? Certainly. There are multiple reasons why kernel project releases happen "a few days apart". It is mostly a manual process and you can probably guess whose time is being spent on it. There is silver lining, though, as Nexus promotions take ~30 minutes for most projects, not 2+ hours like they used to just two months ago. Now if we only had reliable automation taking advantage of that... Regards, Robert |
|
|