On Tue, Mar 26, 2019 at 2:44 AM Ivan Kelly wrote:
> Hi folks,
>
> Looking at doing the final tasks for the 4.8.2 release and stuck on
> the docker bit. It's not that I don't see what has been done before,
> but more that what is there is so so wrong.
>
> Take 4.8.1 release for example. The tarball for that release was cut
> from b4a2b1, yet the tag for that release is bf6149. bf6149 doesn't
> exist on branch-4.8.
>
> Instead, after b4a2b1 is cb8b76 which reverts 4.8.1 to 4.8.1-SNAPSHOT.
> So versions are going backwards in the branch.
>
> My bigger concern for now is the docker + tag bit. The tag should
> represent exactly what we released as artifacts.
>
> Who has control of the docker autobuild settings? From reading the
> docks, you can set a regex and use a capture group to set the version.
> So for docker we could have additional tags, docker/release-4.8.2,
> which lives on the branch-4.8. Another alternative is to move the
> dockerfile into a different repo.
That’s a known issue. The auto build is controlled by ASF. We have
discussed that before and came up the conclusion of current approach. There
is a BP to move dockerfile to a different repo. It just need someone to
complete the BP.
>
> Anyhow, for now I'm going to set the tag to what was actually released.
If you did so, you will not release 4.8.2 image, no?
Instead of doing a different way at the last phase of releasing a release,
I would suggest following the guide that was agreed by the community, and
work on the BP to move the dockerfile to a different repo in next release.
>
> -Ivan
>
