cisagov / cisagov/skeleton-docker
Explain the versioning of Docker images in the README
- Dominant language
- Shell
- Stars
- 22
- Forks
- 14
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 4
Description
# 💡 Summary #
We should explain the slight nuance of how we version Docker images in the README.
## Motivation and context ##
As mentioned in https://github.com/cisagov/skeleton-docker/pull/230#discussion_r2079699458 it was unclear why the image's version was only getting a bump to the build. The scenario with a Docker image containerizing a specific project is what led to this uncertainty and we should spell out more clearly in the README this approach to versioning.
## Implementation notes ##
The README should explain versioning when containerizing a particular application vs. an image configuration that does a specific task. When containerizing the version is tied specifically to the version of the application being containerized. This means that changes which would otherwise cause a version bump (using a new version of Python in the image, etc.) only result in a bump of the build and not a minor or patch version bump. This is contrary to how we would version a Docker image that performs a particular task.
## Acceptance criteria ##
- [ ] The README correctly explains the different approaches to versioning in our Docker projects.
Contributor guide
Research direction
Start with the README and review the linked pull request discussion for the versioning ambiguity. Explain the two approaches for Docker projects—containerizing a particular application versus performing a specific task—and ensure the README covers the stated build, minor, and patch versioning behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 1/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 55/100