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
