Usually the maven release plugin is used for this, which would:
· Checkout SNAPSHOT version poms, e.g. “1.1-SNAPSHOT”
· Update poms to release version, e.g. “1.1”
· Build and run all tests
· Commit release version poms into git repo
· Tag this “release
Hi Eric,
To help the discussion on tagging, I would like to indicate that tagging is
made in multiple locations.
From what I know I see:
1) Tagging at the repository level: that was done by LF when we had the
first release of Amsterdam on Nov 16 and then later for the maintenance release
Does anyone has any input on the same?
I think it is *critical* that we can deliver tagged artifacts (whether maven,
docker *and code*) for each of our release. Most importantly, for Beijing
coming in a few weeks.
We had a discussion last week on the #lf-releng channel, and it seems the issue
Hi, Eric,
I agree with you: this indeed a concern.
Right now, Gildas, Ran and Gary are working with Linux foundation on this one
and hopefully to get a solution very soon. And I also expect a stable master
branch build, meaning we could run some basic sanity testing, more
specifically, passing h
Hello
We still have some problems in the ONAP versioning/tagging.
In the Amsterdam version environment file
(https://git.onap.org/demo/plain/heat/ONAP/onap_openstack.env?h=amsterdam) ,
there is still one project based on master branch.
The Docker tags are not all aligned (some start with v, oth