It's the same process we would follow for a single simultaneous release. The difference is that each component would be (and presently ONAP does this) producing their own staging repository.
So, the release is then a matter of identifying which repositories are part of the release and doing the artifact signing on those and releases in nexus to the release repository. The Simultaneous Release would be more of an identifying what components are actually part of the tested SR and potentially some final single produced downloadable object that doesn't do the build, but just incorporates the individually released components. LF Release Engineering (RelEng) has been fixing up our release scripts dealing with this sort of thing. They are now part of the lftools python project [0] [1] (installable via PyPi). ODL itself has started down the road of individual components being able to release off sync from each other with the current Nitrogen release cycle. The odlparent project has already had at least 3 different releases in the middle of the cycle! We expect that the next project up the stack (yangtools) will do that with the Oxygen release as they transition to SemVer which really is a requirement for this to work correctly. We have additional work coming that will allow us to automate the artifact signing and will therefore allow us to move more of the release processes into the hands of the community itself instead of relying on RelEng for so much of it. -Andy- [0] https://gerrit.linuxfoundation.org/infra/#/admin/projects/releng/lftools [1] https://github.com/lfit/releng-lftools On 07/20/2017 10:41 AM, Gary Wu wrote: > Hi Andy, > > Can you chime in on how the release process would work (vis-à-vis use of > staging repos, artifact signings, etc.) if ONAP decides to have independent > version numbers and possibly independent release cycles for each module? > > Thanks, > Gary > > > -----Original Message----- > From: onap-discuss-boun...@lists.onap.org > [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gino Fraboni > Sent: Thursday, July 20, 2017 7:04 AM > To: SPATSCHECK, OLIVER (OLIVER) <spat...@research.att.com>; Yunxia Chen > <helen.c...@huawei.com> > Cc: onap-discuss@lists.onap.org > Subject: Re: [onap-discuss] Versioning for Amsterdam > > > I'll throw in my +1 for version 2 as well. > And semantic versioning makes complete sense to me. > > > Gino Fraboni > Senior Software Developer > Amdocs Data Experience > > > > A Platinum member of ONAP > Read the latest on Amdocs.com and the Amdocs blog network – and follow us on > Facebook, Twitter, LinkedIn and YouTube. > > > > -----Original Message----- > From: onap-discuss-boun...@lists.onap.org > [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of SPATSCHECK, OLIVER > (OLIVER) > Sent: Thursday, July 20, 2017 9:54 AM > To: Yunxia Chen <helen.c...@huawei.com> > Cc: onap-discuss@lists.onap.org > Subject: Re: [onap-discuss] Versioning for Amsterdam > > > I agree that we should do 3.) independent of 1.) and 2.) ( Again I don’t > think there has been a final decision but I din’t hear any opposition to 3. > so far). > > As for: > > " AAI version 2.0.3, AAF version 1.0.8, Clamp version 0.9.0.” > > I think that’s actually a good thing. > > First we are using 3rd party software of different versions anyway. All those > components depend on often hundreds of jar files which have all kind of > version numbers and version number schemes. So if we are going with 2.) we > are treating other components not differently as we would treat external > components from a build perspective. > > Also above would more honestly represent maturity. E.g. if we are introducing > a new component and ONAP itself is in release 10.X.X should the “beta” > version of that new component have a 10.X.X release number of a 0.X.X release > number. Giving it a 10.X.X release number as the first release is very > misleading… . Also easier for CICD if we ever decided to go that route. > > As for the question if there would be one version per project or repo I would > really leave this up to the projects to work out. If we can handle one per > project the build infrastructure will also be able to handle one per repo. > > I like Pam’s suggestion. Let’s set up some time to close on this next week at > the virtual dev meeting. > > Gildas can you set up the discussion as part of the release planing? > > Thx > > Oliver > >> On Jul 19, 2017, at 7:27 PM EDT, Yunxia Chen <helen.c...@huawei.com> wrote: >> >> Option 3 is an alternative as option 1. I +1 for option 1 or option 3 from >> Integration point of view and end user point of view. >> >> I understand that the “freedom” on each project with its own versioning. As >> stated in Gildas’s email, currently we have 20+ projects which will >> participate the Arsterdam simultaneous release, it will be very hard for us >> to test all those combinations and maintain that mapping. >> >> Regards, >> >> Helen Chen >> >> From: <onap-discuss-boun...@lists.onap.org> on behalf of Gildas Lanilis >> <gildas.lani...@huawei.com> >> Date: Wednesday, July 19, 2017 at 1:58 PM >> To: "HANSEN, TONY L" <t...@att.com>, "onap-discuss@lists.onap.org" >> <onap-discuss@lists.onap.org> >> Subject: Re: [onap-discuss] Versioning for Amsterdam >> >> To my knowledge, no decision was made on versioning. >> >> If we go with option #2: >> >> Questions: >> 1) Who is maintaining the version dependency? Or ideally how to >> generate automatically that dependency graph? >> 2) When we will deliver Amsterdam later in November, we are going to >> say: We are delivering Amsterdam Release 1.0.0 that embeds the following >> components: AAI version 2.0.3, AAF version 1.0.8, Clamp version 0.9.0. and >> so on. Are we comfortable with that approach? >> >> 3) Independently of option #1 or #2, do we agree to adopt Semantic >> Versionning? >> >> <image001.jpg> >> >> Thanks, >> Gildas >> ONAP Release Manager >> 1 415 238 6287 >> >> From: onap-discuss-boun...@lists.onap.org >> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of HANSEN, TONY L >> Sent: Wednesday, July 19, 2017 1:24 PM >> To: onap-discuss@lists.onap.org >> Subject: Re: [onap-discuss] Versioning for Amsterdam >> >> Here’s my +1 as well for option 2. I also like Randa’s addition, but make >> sure you also add in “Prototype” or “PreRelease” or something along those >> lines for issues filed against the current pre-Amsterdam code base. >> >> Tony >> >> From: <onap-discuss-boun...@lists.onap.org> on behalf of "MAHER, RANDA" >> <rx1...@att.com> >> Date: Wednesday, July 19, 2017 at 3:43 PM >> To: "TALASILA, MANOOP" <talas...@research.att.com>, >> "onap-discuss@lists.onap.org" <onap-discuss@lists.onap.org>, "SPATSCHECK, >> OLIVER" <spat...@research.att.com> >> Subject: Re: [onap-discuss] Versioning for Amsterdam >> >> >> I would further propose an enhancement for Option 2: >> >> All Jira project be updated to include a new field called Release Name and >> entries for that field be from a pull down menu that would include >> Amsterdam, Beijing, and any future release added when the name is >> determined. Further, that Affects Version and Fix Version be used to >> identify the version number in which an issue is found in and/or submitted >> in. >> >> Having a separate Release Name Attribute in Jira will allow to easily build >> query to collect all the items being submitted for Amsterdam and we don’t >> have to worry about different version numbers being used across different >> projects for the same major release. >> >> Randa >> >> From: onap-discuss-boun...@lists.onap.org >> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of TALASILA, MANOOP >> Sent: Wednesday, July 19, 2017 2:51 PM >> To: onap-discuss@lists.onap.org; SPATSCHECK, OLIVER >> <spat...@research.att.com> >> Subject: Re: [onap-discuss] Versioning for Amsterdam >> >> +1 for option 2 (from Portal team) >> >> Manoop >> >> On Wed, Jul 19, 2017 at 11:06 AM -0400, "SPATSCHECK, OLIVER (OLIVER)" >> <spat...@research.att.com> wrote: >> >> *** Security Advisory: This Message Originated Outside of AT&T ***. >> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. >> >> >> >> On the OOM call the question of versioning came up and as this is a larger >> issue across projects David and I decided to bring it up with the larger >> community. I know we have discussed this before but I am not sure we made a >> final decision for Amsterdam (sorry if there was a decision I missed but >> nobody on the call was aware of any decision…). >> >> >> >> The question is how to handle the fact that the seed code is tagged with >> different version numbers > 1 already. >> >> >> >> There are really two options to fix that. >> >> >> >> 1. We try to keep the version numbers all in sync and in sync with the >> release number which will require “down versioning” some of the code with >> all the problems that will cause with dependencies and artifact caching. It >> will also be difficult to maintain as we are applying patches after the >> Amsterdam release is out (a patch to one component would trigger a version >> update to all other components). >> >> >> >> 2. We allow each repo to manage there own version number and then the >> Amsterdam release is just really a collection of artifacts with different >> version numbers properly tagged/referenced. >> >> >> >> I think most people I talked to prefer 2. >> >> >> >> Do we have consensus on this? >> >> >> >> Does the TSC have to officially bless this? >> >> >> >> Thx >> >> >> >> Oliver >> >> _______________________________________________ >> onap-discuss mailing list >> onap-discuss@lists.onap.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI&m=97tnblRmZ70OyAKsxFDT2fXKIiukpDnKyldFwNp6OW4&s=xJcPtN7LfTs5ocAlsdeyAFCnqGOVOMr4uge4k91fPy4&e= >> > > _______________________________________________ > onap-discuss mailing list > onap-discuss@lists.onap.org > https://lists.onap.org/mailman/listinfo/onap-discuss > This message and the information contained herein is proprietary and > confidential and subject to the Amdocs policy statement, > > you may review at https://www.amdocs.com/about/email-disclaimer > <https://www.amdocs.com/about/email-disclaimer> > _______________________________________________ > onap-discuss mailing list > onap-discuss@lists.onap.org > https://lists.onap.org/mailman/listinfo/onap-discuss > -- Andrew J Grimberg Lead, IT Release Engineering The Linux Foundation
signature.asc
Description: OpenPGP digital signature
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
