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
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,
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
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
