At the moment everything is tied to 'latest' which is called 'snapshot'. This imposes a huge non-deterministic risk for actual deployments and makes it really hard to reference script / artefact versions in e.g. bug reports or questions.

The main issue is that the maven style 'snapshot' is used without the actual maven implementation using distinct versions internally. maven allows to point to latest (with snapshot) but is versioned in the metadata. So you always can tell what 'version' you are using.

https://nexus.onap.org/content/sites/raw/org.onap.demo/heat/ONAP/1.1.0-SNAPSHOT

omits this information as it is just a pointer to latest. You can download things at 9:00 am in the morning but get a totally different result at 9:01 am (pick any time later, one minute to just make a point)

the same is true with docker image tagging. running the exact same script a minute later can pull in new docker images references as the same snapshot tag.

Definition of done:

• Scripts can be referenced with a proper version string
• docker images can be referenced with a proper version string
• a changelog is maintained alongside version increments 

I do understand that this will need some work but the current situation is depending on temperature as well as moon and star constellations

btw. http://kief.com/the-conflict-between-continuous-delivery-and-traditional-agile.html

Friction point: snapshot/release builds

Many development teams divide software builds into two types, “snapshot” builds and “release” builds. This is not specific to Agile, but has become strongly embedded in the Java world due to the rise of Maven, which puts the snapshot/build concept at the core of its design. This approach divides the development cycle into two phases, with snapshots being used while software is in development, and a release build being created only when the software is deemed ready for release.

This division of the release cycle clearly conflicts with the Continuous Delivery philosophy that software should always be ready for release. The way CD is typically implemented involves only creating a build once, and then promoting it through multiple stages of a pipeline for testing and validation activities, which doesn’t work if software is built in two different ways as with Maven.