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]> on behalf of "MAHER, RANDA"
<[email protected]>
Date: Wednesday, July 19, 2017 at 3:43 PM
To: "TALASILA, MANOOP" <[email protected]>,
"[email protected]" <[email protected]>, "SPATSCHECK,
OLIVER" <[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]] On Behalf Of TALASILA, MANOOP
Sent: Wednesday, July 19, 2017 2:51 PM
To: [email protected]; SPATSCHECK, OLIVER <[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
