[Proposal] Image Versioning

[dcasavant]

Is your feature request related to a problem? Please describe. As a consumer of the docker-pega-web-ready image, I want more control over the adoption of incoming changes in my pipeline.

Current image versioning and tagging policy

Branch	Tag
master	2.1.0, latest
v2.0.0	2.0.0
v0.1-Pega7	none

Describe the solution you'd like

Branch	Tag
master	2.1.0-%BUILD%, 2.1.0, latest
v2.0.0	2.0.0-%BUILD%, 2.0.0
v0.1-Pega7	none

The %BUILD% value must be unique for every build and sequential for each branch. Unfortunately using something as easy as the travis build # would cause gaps between image version numbers and may result in confusion. If a build number is not feasible, perhaps a build date would be a good option.

[Max-Levitskiy]

@dcasavant I see it as in a few steps:

• On push in the master, we read the latest release (or v* tag), split it by the last dot (I think better to update patch part version) or by a dash (in case we want to have "x.x.x-${incrementalVersion}" format). After we increment the version number and push tag or release (or create pre-release version if we want "manual approve" step). Repeat incrementation if fail because other job pushed the release at the same time.
• If we don't want to use approve step, we can use "Github actions"/Travis to push tag/release and the "docker hub builds" configuration by tag with regexp for the second step. Other option: do everything (push tags/release, build image and push) in one Github or Travis pipeline.
• If we want to do it with pre-approve or manual release creation to trigger the build it's better to use GitHub actions.

Manual approve (optional):

1. Creation pre-release and promote it manually to release.
2. Create release manually from a tag. Release triggers image build and push.

[kishorv10]

This was initially addressed in #153 . With the recent changes images are getting published in below fashion latest, 3-jdk11, 3-jdk-17, 3.1.<build#>-jdk11, 3.1.<build#>-jdk17