Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: replace Amsterdam, Beijing by ONAP

...

The diagram below has 2 Major releases. Theses are Named Release "1.0.0-AmsterdamONAP" and "2.0.0-BeijingONAP".

1.0.0-Amsterdam ONAP is a Major Release, and embeds (in this example) 2 Artifact Release, "AAI Docker" version 1.0.0 and "AAF Docker" version 2.0.0.

...

The version number are documented in the o-parent manifest.

Image Modified

Example: 1 Major, 1 Service and 1 Enhancement Releases

...

The diagram below has 3 Named Releases (delivered chronologically in that order):

  1. 1.0.0-AmsterdamONAP
  2. 1.0.1-AmsterdamONAP
  3. 1.1.0-AmsterdamONAP

1.0.0-Amsterdam ONAP is a Major Release.

1.0.1-Amsterdam ONAP is a Service Release and is released to deliver (for example) a security issue in "AAI cpt 1" component. Note the third digit is now "4".

1.1.0-Amsterdam ONAP is an Enhancement Release and is released to deliver (for example) a backward compatible functionality in "AAF cpt 1" and "AAF cpt 2" components. Note the second digits are now "1" and "7". Note also there is no version continuity in "AAF cpt 2" between the Service (4) and the Enhancement (7) Releases. This is acceptable as the team may have delivered intermediate "Artifact Release" that were not embedded with a "Named Release".

Major, Minor, PatchImage RemovedImage Added

Semantic Versioning

...

Now things happen and we may need to deliver a hot fix (also called patch) into the latest available Release.
To perform the patch delivery, we simply perform the hot fix in the delivery branch, and tag it (1.0.1-AmsterdamONAP). 
Once the hot fix is delivered (and everyone is back to happiness), we will decide how to carry over the changes into the current Release branch (Beijing branch on the case below). Most probably cherry pick technique will apply. 
It may also happen that we need to carry over into the latest available Release (Amsterdam) some fixes or new backward functionalities that were discovered while developing current Release (Beijing). Here too, we will decide on the best options to carry over changes into the current available Release (Amsterdam) and Release and make a new Release (1.1.0-AmsterdamONAP).

As a guiding principle, the ONAP community keeps its focus on developing in Master branch. Hot fix process will be more the exception than the rule.

...