Tags, version numbers and docker

[Ivan Kelly <iv...@apache.org>]

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.

Anyhow, for now I'm going to set the tag to what was actually released.

-Ivan

Re: Tags, version numbers and docker

[Sijie Guo <gu...@gmail.com>]

I am fine with it if there is someone pushing the process forward.

- Sijie

On Thu, Mar 28, 2019 at 4:12 AM Jia Zhai <zh...@gmail.com> wrote:

> +1 for ivan's idea
>
> Best Regards.
>
>
> Jia Zhai
>
> Beijing, China
>
> Mobile: +86 15810491983
>
>
>
>
> On Thu, Mar 28, 2019 at 6:55 PM Enrico Olivelli <eo...@gmail.com>
> wrote:
>
> > Il giorno gio 28 mar 2019 alle ore 09:26 Ivan Kelly <iv...@apache.org>
> > ha scritto:
> > >
> > > To clarify, what I intend to do here is.
> > >
> > > 1. Merge change from [1] to all live branches, so docker image will
> > > build directly from the voted on tag.
> > > 2. Get infra to add another autobuild rule that matches on
> > > release-([0-9.]+)\/docker, so that 4.8.2 and maybe 4.9.1 can be built
> > > with this change. This rule would not be used after that point.
> >
> >
> > +1
> >
> > >
> > > -Ivan
> > >
> > > [1]
> >
> https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9
> > >
> > > On Wed, Mar 27, 2019 at 10:52 AM Ivan Kelly <iv...@apache.org> wrote:
> > > >
> > > > > 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.
> > > >
> > > > This was a known issue a year ago. Nothing has moved on it, so I'm
> > > > trying to make movement now.
> > > >
> > > > > If you did so, you will not release 4.8.2 image, no?
> > > >
> > > > The image isn't part of the official release. At most it's a
> > > > convenience binary of the official release. However, at present it
> > > > isn't even that since it's generated from a tag which has not been
> +1d
> > > > by 3 PMC members.
> > > >
> > > > > 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.
> > > >
> > > > There's a fundamental release issue here. The official release is the
> > > > source tarball. The tag should reflect the contents of the source
> > > > tarball, and it should be possible to generate all binary convenience
> > > > packages from the source tarball.
> > > >
> > > > Things that do not match this criteria should not be presented as
> part
> > > > of the release as they have not been approved by 3 members of the
> PMC.
> > > >
> > > > I'm not going to put my signature on a tag which hasn't been voted
> on.
> > > > Currently whether tags constitute an official release artifact is
> > > > unresolved from a legal POV [1], but they are two clicks away from
> the
> > > > bookkeeper website frontpage so I think we should treat them as such.
> > > >
> > > > I will however fix the process for subsequent releases. The simplest
> > > > fix is to set the BK_VERSION from tag name. This can be done in a
> > > > build hook [2] which dockerhub autobuild[3] will pick up. Really
> > > > though we should build the tarball in a prehook so that the image can
> > > > also be generated for release candidates, so it can be tested and
> > > > voted on along with the rest of the convenience binaries.
> > > >
> > > > -Ivan
> > > >
> > > > [1] https://issues.apache.org/jira/browse/LEGAL-438
> > > > [2]
> >
> https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9
> > > > [3]
> >
> https://cloud.docker.com/repository/registry-1.docker.io/ivankelly/bookkeeper/builds
> >
>

Re: Tags, version numbers and docker

[Jia Zhai <zh...@gmail.com>]

+1 for ivan's idea

Best Regards.


Jia Zhai

Beijing, China

Mobile: +86 15810491983




On Thu, Mar 28, 2019 at 6:55 PM Enrico Olivelli <eo...@gmail.com> wrote:

> Il giorno gio 28 mar 2019 alle ore 09:26 Ivan Kelly <iv...@apache.org>
> ha scritto:
> >
> > To clarify, what I intend to do here is.
> >
> > 1. Merge change from [1] to all live branches, so docker image will
> > build directly from the voted on tag.
> > 2. Get infra to add another autobuild rule that matches on
> > release-([0-9.]+)\/docker, so that 4.8.2 and maybe 4.9.1 can be built
> > with this change. This rule would not be used after that point.
>
>
> +1
>
> >
> > -Ivan
> >
> > [1]
> https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9
> >
> > On Wed, Mar 27, 2019 at 10:52 AM Ivan Kelly <iv...@apache.org> wrote:
> > >
> > > > 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.
> > >
> > > This was a known issue a year ago. Nothing has moved on it, so I'm
> > > trying to make movement now.
> > >
> > > > If you did so, you will not release 4.8.2 image, no?
> > >
> > > The image isn't part of the official release. At most it's a
> > > convenience binary of the official release. However, at present it
> > > isn't even that since it's generated from a tag which has not been +1d
> > > by 3 PMC members.
> > >
> > > > 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.
> > >
> > > There's a fundamental release issue here. The official release is the
> > > source tarball. The tag should reflect the contents of the source
> > > tarball, and it should be possible to generate all binary convenience
> > > packages from the source tarball.
> > >
> > > Things that do not match this criteria should not be presented as part
> > > of the release as they have not been approved by 3 members of the PMC.
> > >
> > > I'm not going to put my signature on a tag which hasn't been voted on.
> > > Currently whether tags constitute an official release artifact is
> > > unresolved from a legal POV [1], but they are two clicks away from the
> > > bookkeeper website frontpage so I think we should treat them as such.
> > >
> > > I will however fix the process for subsequent releases. The simplest
> > > fix is to set the BK_VERSION from tag name. This can be done in a
> > > build hook [2] which dockerhub autobuild[3] will pick up. Really
> > > though we should build the tarball in a prehook so that the image can
> > > also be generated for release candidates, so it can be tested and
> > > voted on along with the rest of the convenience binaries.
> > >
> > > -Ivan
> > >
> > > [1] https://issues.apache.org/jira/browse/LEGAL-438
> > > [2]
> https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9
> > > [3]
> https://cloud.docker.com/repository/registry-1.docker.io/ivankelly/bookkeeper/builds
>

Re: Tags, version numbers and docker

[Enrico Olivelli <eo...@gmail.com>]

Il giorno gio 28 mar 2019 alle ore 09:26 Ivan Kelly <iv...@apache.org>
ha scritto:
>
> To clarify, what I intend to do here is.
>
> 1. Merge change from [1] to all live branches, so docker image will
> build directly from the voted on tag.
> 2. Get infra to add another autobuild rule that matches on
> release-([0-9.]+)\/docker, so that 4.8.2 and maybe 4.9.1 can be built
> with this change. This rule would not be used after that point.


+1

>
> -Ivan
>
> [1] https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9
>
> On Wed, Mar 27, 2019 at 10:52 AM Ivan Kelly <iv...@apache.org> wrote:
> >
> > > 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.
> >
> > This was a known issue a year ago. Nothing has moved on it, so I'm
> > trying to make movement now.
> >
> > > If you did so, you will not release 4.8.2 image, no?
> >
> > The image isn't part of the official release. At most it's a
> > convenience binary of the official release. However, at present it
> > isn't even that since it's generated from a tag which has not been +1d
> > by 3 PMC members.
> >
> > > 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.
> >
> > There's a fundamental release issue here. The official release is the
> > source tarball. The tag should reflect the contents of the source
> > tarball, and it should be possible to generate all binary convenience
> > packages from the source tarball.
> >
> > Things that do not match this criteria should not be presented as part
> > of the release as they have not been approved by 3 members of the PMC.
> >
> > I'm not going to put my signature on a tag which hasn't been voted on.
> > Currently whether tags constitute an official release artifact is
> > unresolved from a legal POV [1], but they are two clicks away from the
> > bookkeeper website frontpage so I think we should treat them as such.
> >
> > I will however fix the process for subsequent releases. The simplest
> > fix is to set the BK_VERSION from tag name. This can be done in a
> > build hook [2] which dockerhub autobuild[3] will pick up. Really
> > though we should build the tarball in a prehook so that the image can
> > also be generated for release candidates, so it can be tested and
> > voted on along with the rest of the convenience binaries.
> >
> > -Ivan
> >
> > [1] https://issues.apache.org/jira/browse/LEGAL-438
> > [2] https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9
> > [3] https://cloud.docker.com/repository/registry-1.docker.io/ivankelly/bookkeeper/builds

Re: Tags, version numbers and docker

[Ivan Kelly <iv...@apache.org>]

To clarify, what I intend to do here is.

1. Merge change from [1] to all live branches, so docker image will
build directly from the voted on tag.
2. Get infra to add another autobuild rule that matches on
release-([0-9.]+)\/docker, so that 4.8.2 and maybe 4.9.1 can be built
with this change. This rule would not be used after that point.

-Ivan

[1] https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9

On Wed, Mar 27, 2019 at 10:52 AM Ivan Kelly <iv...@apache.org> wrote:
>
> > 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.
>
> This was a known issue a year ago. Nothing has moved on it, so I'm
> trying to make movement now.
>
> > If you did so, you will not release 4.8.2 image, no?
>
> The image isn't part of the official release. At most it's a
> convenience binary of the official release. However, at present it
> isn't even that since it's generated from a tag which has not been +1d
> by 3 PMC members.
>
> > 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.
>
> There's a fundamental release issue here. The official release is the
> source tarball. The tag should reflect the contents of the source
> tarball, and it should be possible to generate all binary convenience
> packages from the source tarball.
>
> Things that do not match this criteria should not be presented as part
> of the release as they have not been approved by 3 members of the PMC.
>
> I'm not going to put my signature on a tag which hasn't been voted on.
> Currently whether tags constitute an official release artifact is
> unresolved from a legal POV [1], but they are two clicks away from the
> bookkeeper website frontpage so I think we should treat them as such.
>
> I will however fix the process for subsequent releases. The simplest
> fix is to set the BK_VERSION from tag name. This can be done in a
> build hook [2] which dockerhub autobuild[3] will pick up. Really
> though we should build the tarball in a prehook so that the image can
> also be generated for release candidates, so it can be tested and
> voted on along with the rest of the convenience binaries.
>
> -Ivan
>
> [1] https://issues.apache.org/jira/browse/LEGAL-438
> [2] https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9
> [3] https://cloud.docker.com/repository/registry-1.docker.io/ivankelly/bookkeeper/builds

Re: Tags, version numbers and docker

[Ivan Kelly <iv...@apache.org>]

> 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.

This was a known issue a year ago. Nothing has moved on it, so I'm
trying to make movement now.

> If you did so, you will not release 4.8.2 image, no?

The image isn't part of the official release. At most it's a
convenience binary of the official release. However, at present it
isn't even that since it's generated from a tag which has not been +1d
by 3 PMC members.

> 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.

There's a fundamental release issue here. The official release is the
source tarball. The tag should reflect the contents of the source
tarball, and it should be possible to generate all binary convenience
packages from the source tarball.

Things that do not match this criteria should not be presented as part
of the release as they have not been approved by 3 members of the PMC.

I'm not going to put my signature on a tag which hasn't been voted on.
Currently whether tags constitute an official release artifact is
unresolved from a legal POV [1], but they are two clicks away from the
bookkeeper website frontpage so I think we should treat them as such.

I will however fix the process for subsequent releases. The simplest
fix is to set the BK_VERSION from tag name. This can be done in a
build hook [2] which dockerhub autobuild[3] will pick up. Really
though we should build the tarball in a prehook so that the image can
also be generated for release candidates, so it can be tested and
voted on along with the rest of the convenience binaries.

-Ivan

[1] https://issues.apache.org/jira/browse/LEGAL-438
[2] https://github.com/ivankelly/bookkeeper/commit/e247ef705f055706604ba2f862c1006a8cf817e9
[3] https://cloud.docker.com/repository/registry-1.docker.io/ivankelly/bookkeeper/builds

Re: Tags, version numbers and docker

[Sijie Guo <gu...@gmail.com>]

On Tue, Mar 26, 2019 at 2:44 AM Ivan Kelly <iv...@apache.org> 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
>