I’ll set up a call to discuss this further. I think we need to have a TSC decision on :
- Do we want to freeze artifacts from seed code release 1.0.0 (the stable one) and/or 1.1.0 (the enhanced and catch up code) or not ? o A mitigated action could be to just go and bless the Docker containers from the stable build that we have – which is what people are trialing against and rename the stable branch to something more meaningful (just keep it for historical purpose and as an easy way for people to see the code they are running their trial on), then for the current master we can probably move away from staging and go to snapshots as suggested below. - Do we formally remove artifact version numbering from ONAP release numbering ? o If we do, then we could question the whole staging approach. Few things to note when moving away from staging: - I don’t think there is a formal list of which artifacts are coming from staging, now disabling the staging repo will quickly highlight them. This will need attention from all teams to fix their builds with proper snapshots. We’ve noticed that the build nodes do not start from an empty .m2 repository so it might obfuscate issues. - We will need to setup daily snapshot builds (right now we have daily release against staging build) to keep up building our daily docker images, sonar scans etc… - we will need to adapt the docker images tag to reflect that situation - We will need each team to adapt their jjb jobs and templates to have a way to re-enable staging easily Just to say that it’s not straightforward and will most probably take a few days before we get all components buildable again on master Regards Christophe From: SPATSCHECK, OLIVER Sent: Friday, May 26, 2017 2:19 PM To: Andrew Grimberg <agrimb...@linuxfoundation.org> Cc: Gary Wu <gary.i...@huawei.com>; Coquelin, Sebastien <sebastien.coque...@bell.ca>; Closset, Christophe <cc6...@intl.att.com>; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml Would have to talk to all the teams to get the details but I think most artifacts need to be locked down. Please remember that since we created the 1.0.0 branch we have been contributing code based on two additional internal releases into the seed repos. This new code base has not been fully tested yet (we took some shortcuts)to catch up. So if we remove the 1.0.0 branch we don’t have a working system right now. I also think that artifact versioning shouldn’t match the ONAP release versioning. I think trying to keep that all in sync with the number of artifacts we have is a nightmare. E.g. will you be rolling the artifact version number on the Open-O artifacts back to 1.0.0? I would just leave them where they are. Otherwise you will have people with incorrect artifacts in there maven caches. This seems to be just generating additional work/confusion with little practical value. Oliver On May 25, 2017, at 5:55 PM, Andrew Grimberg <agrimb...@linuxfoundation.org<mailto:agrimb...@linuxfoundation.org>> wrote: On 05/25/2017 02:36 PM, Gary Wu wrote: That makes sense given that staging artifacts were supposed to exist only long enough to decide whether they're good to release or not; they were not meant to be used as long-lived build dependencies. I think the right thing to do is to move away from this "build against staging" approach relatively soon. Given that our formal 1st release is November, and assuming that the release artifact version will be "1.0.0", I see two options: 1. Do not release any thing from staging right now. Change all artifact versions to 1.0.0-SNAPSHOT. 2. For the subset of artifacts that need to be "locked down", actually release the staging candidates right now as 1.0.0-RC0 or some such. Then change all artifact versions to 1.0.0-SNAPSHOT, except explicit dependencies on the released 1.0.0-RC0 artifacts where desired. Any other ideas? Do we have a full list of the artifacts that explicitly need to be served up from staging repos right now? I'm hoping this list is relatively short. Not something I can answer. I would hope that the seed projects can answer that. -Andy- -- Andrew J Grimberg Lead, IT Release Engineering The Linux Foundation
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
