Agreed with Option 2. It seems a standard practice to collect the various versioned components into a manifest.
In A&AI we have a decomposed microservices architecture, and actually tried our own version of Option 1 for a while. Unsurprisingly, it created more overhead and confusion among development, and are trying to move to #2 internally. Cheers. On 19 July 2017 at 11:06, SPATSCHECK, OLIVER (OLIVER) < [email protected]> wrote: > > 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 >
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
