Find versioning scheme

[widhalmt]

We should agree on a versioning scheme for this project so we can start building a roadmap with milestones as soon as possible.

There are several versions involved and we should decide which version will be represented where.

Things to consider and things that came up in discussions within the team:

• We want to support several versions of Icinga 2 at the same time
• The base image has its versions, too. Since we're running in Docker this shouldn't make any difference and could be ignored. Nevertheless we should provide for a way to update packages aside from Icinga related tools aka build on newer base images
• We should definitely agree on a versioning scheme that works for all Icinga related containers to come. There's no need for synchronised versions, but the logic should work everywhere

It looks like a good idea to have versions for the Docker specific repositories (like this one) which are completely disconnected from the versions of the tools that are to be dockerized and the base image. The question is, should the version be in any case reflected in the tags and versions of the containers? At a first glance, I'd say no. The user cares if they are using Icinga 2.11.3 or Icinga 2.12.0 but not if the container was built with version 1.2 or version 5.13 of the Dockerfile. On the other hand, what if we need to change something on the interfaces to the outside world? By now we haven't devided on how to get configuration into the container. What if we don't choose wisely and have to change it later on?

The short version would be to just use semantic versioning for this repo (esp. the Dockerfile).

[bodsch]

My suggestion would be to use the version of Icinga2 as the version string.

Examples:

• icinga2-2.12.2 - the exact version of icinga2 im as container.
• icinga2-1.12 - the last available minor version vin icinga2.
• icinga2-latest - would always be the last stable (!) version

For pre releases (RC, beta whatever) corresponding post or pre fixes would be necessary.

If different base distributions (debian ubuntu, centos) are used, this can also be included in the naming scheme. For example: icinga2-2.12-debian(10).

I would generally use existing conatiners such as nginx for this. https://hub.docker.com/_/nginx / https://hub.docker.com/_/mariadb

[widhalmt]

I'm just unsure if we should sync the versions of this project to Icinga 2 version. I was thinking of different Icinga 2 versions being built with the same version of the Dockerfile.

e.g. icinga-docker-1.0.0 could build the Docker containers icinga/icinga2-2.12.0, icinga/icinga2-2.12.1 and icinga/icinga-2.13.0.

What keeps bugging me is if this would interfere with the build process, pipelines or anything else.

If we have a common version of Dockerfiles we definitely would need to make sure that the file could handle different peculiarities of different Icinga 2 versions. Automated tests would have to take the version of Icinga 2 into account, too.

Having one Icinga 2 version per Dockerfile version would help with easier automated tests and to build the Dockerfile for this specific version. But we would need to maintain several branches at least one for each Icinga 2 version supported and iterate to all of them if we want to update just the base image.

This just to inform you all, that @bodsch and me are talking right now about this issue. You're very welcome to chime in here in the issue.

[Al2Klimov]

Don't we already have a scheme?

[lippserd]

Don't we already have a scheme?

Yes.