Gary, thanks for the summary.
I would NOT try to keep the version numbers in sync. Either way creates work and I believe keeping them in sync creates much more work. E.g. if you apply a patch to a jar file (let’s say an emergency security patch which will come..) in a release branch does that mean everybody has to generate a jar file with the matching version number and push it out even if nothing changed? So that creates work for 31 projects (current count) when one project fixes a bug in one jar file. Does even the documentation projects have to bump the version number on there documentation because somebody edited a jar file? That either slows down patching or generates a lot of work for a lot of people. Even keeping mayor version numbers in sync is questionable to me. E.g. if two years from now a new project is started and ONAP is on release 4.x.x does that mean a fairly new jar file should start out with release number 4.x.x ? That would indicate much more maturity then the jar file probably has at that point in time and is misleading to the user. So I would have an ONAP release number and version numbers of artifacts which tie into a release. I am not quite sure why that would be more work then above. Oliver > On May 30, 2017, at 6:49 PM EDT, Gary Wu <gary.i...@huawei.com> wrote: > > A quick summary of our call this morning with myself, Christophe, and > Sebastien: > > The consensus is that we’re ok to move the Java artifacts back to SNAPSHOT > versioning (and thereby removing build dependencies on Staging repos) as long > as the docker images can continue with the current STAGING tags. Christophe > will check back with AT&T teams to organize this effort, hopefully to be done > within a few days. > > One big open issue for the TSC to decide is whether we want to keep all Java > artifact versions in sync across all modules/projects (i.e. version 1.0.0) > for each ONAP release, or if we want to support a mix of independent version > numbers and release cycles per project or even per jar file. For reference, > Open-O decided on the former in order to minimize support and maintenance > costs. > > Thanks, > Gary > > > From: Closset, Christophe [mailto:cc6...@intl.att.com] > Sent: Monday, May 29, 2017 6:22 AM > To: SPATSCHECK, OLIVER <spat...@research.att.com>; Andrew Grimberg > <agrimb...@linuxfoundation.org> > Cc: Gary Wu <gary.i...@huawei.com>; Coquelin, Sebastien > <sebastien.coque...@bell.ca>; onap-discuss@lists.onap.org > Subject: RE: [onap-discuss] Staging repo in settings.xml > > 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> > 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
