In Docker tags, it is conventional and recommended to use dots (.) rather than dashes (-). Docker tags typically follow a format that resembles a versioning scheme, such as major.minor.patch. For example, 1.0.0 or latest.

Here are a few reasons why dots are preferred over dashes:

1. Semantic Versioning: Docker tags often follow semantic versioning principles, where a version number consists of major, minor, and patch components separated by dots (.). This format helps in understanding the compatibility and changes in the image.

2. Consistency: Using dots for versioning tags aligns with the broader software development community's practices, making it easier to understand and integrate with other tools and systems.

3. Compatibility with Docker Registry: Docker registries and tools are designed with the assumption that tags follow a dot-separated format. While dashes are technically allowed, they might lead to confusion or unexpected behavior in certain scenarios.

While Docker allows a degree of flexibility in naming tags (including using dashes), sticking with dots for versioning tags promotes clarity and consistency, which are crucial in software development and deployment workflows. Therefore, it's generally better to use dots (.) in Docker tags, especially when indicating version numbers.

To create a Docker tag that includes the components YYYY (year), CW (calendar week), and a 6-character Git short SHA, you can use a delimiter to separate these components clearly. Given the nature of Docker tags and to ensure readability and consistency, a suitable format would be:

YYYY.CW-GITSHA

Here's what each component represents:

• YYYY: Year, represented by four digits (e.g., 2024).

• CW: Calendar week, typically represented by two digits (e.g., 01 for the first week of the year).

• GITSHA: Git short SHA, the first 6 characters of the Git commit hash.

Example

If today is July 11, 2024, and the Git short SHA is abcdef, the Docker tag could look like this:

2024.28-abcdef

Explanation of the format

• Dot (.) between YYYY and CW: The dot separates the year and the calendar week, providing a clear distinction between these temporal components.

• Dash (-) between CW and GITSHA: The dash separates the calendar week from the Git short SHA, helping to distinguish between the time-based portion and the Git-related portion of the tag.

Advantages of this format

• Readability: Using dots and dashes makes the tag easy to read and understand, aligning with typical versioning practices.

• Consistency: This format is consistent with common Docker tag conventions, ensuring compatibility with Docker registries and tools.

• Clarity: Each component (YYYY, CW, GITSHA) is clearly delineated, making it straightforward to parse and comprehend the tag's meaning.

By following this format (YYYY.CW-GITSHA), you achieve a well-structured Docker tag that incorporates both temporal and source control information in a clear and standardized manner.

Collisions risk

The collision risk depends on the probability of two different commits having the same short SHA within the same calendar week. Let's break down the components:

1. Calendar Week (CW): There are 52 weeks in a year.

2. Git Short SHA: The Git SHA-1 hash is a 40-character hexadecimal string, and the probability of collisions is extremely low even for shorter versions of this hash.

Calculating Collision Probability

For 3-character SHA:

• There are 163=4096163=4096 possible combinations.

• The chance of collision increases with the number of commits, but for practical purposes, the risk remains relatively low for small to moderate repositories.

For 4-character SHA:

• There are 164=65536164=65536 possible combinations.

• This significantly reduces the risk of collisions compared to a 3-character SHA.

Recommendation

Using a 4-character SHA reduces the collision risk significantly compared to a 3-character SHA and is generally sufficient for most practical purposes.