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: <[email protected]> on behalf of Gildas Lanilis <[email protected]> Date: Wednesday, July 19, 2017 at 1:58 PM To: "HANSEN, TONY L" <[email protected]>, "[email protected]" <[email protected]> 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<http://semver.org/>? [cid:[email protected]] Thanks, Gildas ONAP Release Manager 1 415 238 6287 From: [email protected] [mailto:[email protected]] On Behalf Of HANSEN, TONY L Sent: Wednesday, July 19, 2017 1:24 PM To: [email protected] 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: <[email protected]<mailto:[email protected]>> on behalf of "MAHER, RANDA" <[email protected]<mailto:[email protected]>> Date: Wednesday, July 19, 2017 at 3:43 PM To: "TALASILA, MANOOP" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "SPATSCHECK, OLIVER" <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of TALASILA, MANOOP Sent: Wednesday, July 19, 2017 2:51 PM To: [email protected]<mailto:[email protected]>; SPATSCHECK, OLIVER <[email protected]<mailto:[email protected]>> 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)" <[email protected]<mailto:[email protected]>> 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 [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
