[
https://issues.apache.org/jira/browse/TIKA-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18080130#comment-18080130
]
Tim Allison commented on TIKA-4725:
-----------------------------------
I think I now like this proposal for versioning. It isn't that different from
what we were doing.
## Summary
Move from `4.0.0.0` four-part versions to semver `4.0.0-N` with rolling pointer
tags.
## Current state
- Tags like `3.0.0.0`, `3.0.0.1` — final digit incremented on image rebuilds
- Four-part version is non-standard, doesn't parse as semver, sorts unreliably
- No rolling tag for "latest patch of 3.0"
## Proposal
Publish each build with multiple tags pointing at the same digest:
- `4.0.0-N` — immutable, one per rebuild (N=1,2,3...)
- `4.0.0` — rolling, latest `4.0.0-N`
- `latest` — rolling, newest stable
Example: first build pushes `4.0.0-1` + rolling tags. CVE rebuild pushes
`4.0.0-2` and repoints rolling tags. `4.0.0-1` stays pinned to original digest.
## Rationale
- Standard semver; tooling parses and sorts correctly
- Matches convention users expect (Debian, RPM, official Docker images)
- Users choose pinning strategy: `-N` for reproducibility, `4.0` for
auto-patches, `latest` for lazy
- Reproducible builds and SBOMs work — pinned tags don't move
## Implementation
- Update CI to tag with `${VERSION}-${BUILD_NUMBER}` plus rolling tags on push
- Enable immutable tags on Docker Hub for `-N` pattern (if plan supports)
- Document tag selection guidance in README
## Out of scope
- Multi-arch platform changes (tracked separately)
- Migration of existing 3.x tags (leave as-is)
> Tweaks to dockerhub publishing
> ------------------------------
>
> Key: TIKA-4725
> URL: https://issues.apache.org/jira/browse/TIKA-4725
> Project: Tika
> Issue Type: Improvement
> Reporter: Tim Allison
> Priority: Minor
>
> Many, many thanks to [~ndipiazza] , we have automated pushes to docker hub.
> During the 4.0.0-alpha-1 release, I noticed two things we might want to clean
> up.
> # The 4.0.0-alpha-1 image was released May 4 at 7:45pm (not sure which tz,
> guessing utc?), which was probably during one of my early attempts to make
> the release. The vote email didn't go out until May 5 at 6:41am (ET). The
> push shouldn't happen until after a successful vote, no?
> # How do we handle versioning of docker releases outside of a Tika release?
> For example, if we get a request to bump the base image or an OS dependency?
> We had a homegrown versioning system to tack another number: 3.3.0.0 – was
> the first release with Tika 3.3.0. If we had to bump the underlying os and
> republish with Tika 3.3.0, that would be bumped to 3.3.0.1.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
