[
https://issues.apache.org/jira/browse/TIKA-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18080138#comment-18080138
]
ASF GitHub Bot commented on TIKA-4725:
--------------------------------------
tballison opened a new pull request, #2807:
URL: https://github.com/apache/tika/pull/2807
make release manual (after the vote)
Change versioning from 4.0.0.0 to 4.0.0-1
Add labels 4.0.0-1 is labeled 4.0.0, and then when 4.0.0-2 comes out we
update the label to point to 4.0.0.
Other clean ups we found we needed when pushing 4.0.0-alpha-1.0 from
tika-docker.
> 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)
