You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Willem Jiang <wi...@gmail.com> on 2019/05/04 01:41:33 UTC
Release Camel-K 0.3.3
Hi,
I just found there are release in the github of camel-k 0.3.3
recently. I can only find the vote of camel-k runtime 0.3.3. From my
understanding camel-k is dependent on camel-k runtime, but they are
two different projects. As the official Apache release, we need the
vote of PMC[1]
According to the release distribution guild of ASF[2].
"The Apache infrastructure must be the primary source for all
artifacts officially released by the ASF." We need to put the
artifacts of camel-k into the https://dist.apache.org/repos/dist/.
Please let me know if I missed something.
[1]http://www.apache.org/dev/release-publishing.html#goal
[2]http://www.apache.org/dev/release-publishing.html#distribution
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
R: Re: Release Camel-K 0.3.3
Posted by Andrea Cosentino <an...@yahoo.com.INVALID>.
Also there is no kind of staging for go binaries.
Inviato da Yahoo Mail su Android
Il sab, 4 mag, 2019 alle 8:11, Andrea Cosentino<an...@gmail.com> ha scritto: We can add a goal to push the binary generated on dist. But all the stuff
generated is just go binaries and docker images. It's not like a normal
Java project.
Lets wait for Nicola and Luca about this.
Il sab 4 mag 2019, 03:41 Willem Jiang <wi...@gmail.com> ha scritto:
> Hi,
>
> I just found there are release in the github of camel-k 0.3.3
> recently. I can only find the vote of camel-k runtime 0.3.3. From my
> understanding camel-k is dependent on camel-k runtime, but they are
> two different projects. As the official Apache release, we need the
> vote of PMC[1]
> According to the release distribution guild of ASF[2].
> "The Apache infrastructure must be the primary source for all
> artifacts officially released by the ASF." We need to put the
> artifacts of camel-k into the https://dist.apache.org/repos/dist/.
>
> Please let me know if I missed something.
>
> [1]http://www.apache.org/dev/release-publishing.html#goal
> [2]http://www.apache.org/dev/release-publishing.html#distribution
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
Re: Release Camel-K 0.3.3
Posted by Andrea Cosentino <an...@gmail.com>.
Personally I don't think having the two entries, one on Github and one in
the Apache official link, will confuse the users, since the binaries are
the same.
IMO, it's not a problem and it's allowed. +1 for having the github release
page with the official link
Il giorno ven 17 mag 2019 alle ore 02:44 Willem Jiang <
willem.jiang@gmail.com> ha scritto:
> Hi Nicola,
>
> +1 to cut the camel-k release once to simplify the release process.
> I think we could create an internal account in the docker hub for the
> staging release and publish the snapshot version for internal
> validation.
> Once we have the official source release, we could push the voted
> staging image into Apache docker repo as the final release process.
>
> For the Github release page, it could be better to have one entry
> (Apache official link) for the user to download. In this way the user
> could not be confused to find out which binary is the best one.
>
> Regards,
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, May 17, 2019 at 6:55 AM Nicola Ferraro <ni...@gmail.com>
> wrote:
> >
> > Thanks Willem for taking time for looking into this issue.
> >
> > For staging the binary files, I think it's ok to follow the ServiceComb
> > approach (I assume that the /dev path is for dev builds only and cannot
> be
> > mistaken for the official release path).
> > Also point 3 can be addressed. I hope we can do it with the new website,
> > that I'd like to see online soon.
> >
> > But I think we have a problem with docker images. In other projects,
> docker
> > images are a different way of packaging the binaries, but camel k is a
> > cloud platform and cannot be run without the docker images.
> > This means that if we don't publish the docker images, we're not able to
> > test the software before the vote.
> >
> > So we are asked to release docker images after voting, but cannot vote
> > without them. It's a kind of chicken and eggs problem.
> >
> > On the other side. For camel k, users are not expected to look into
> docker
> > hub to find the software, i.e. we're not using docker hub as a portal to
> > distribute the software to our users. The primary way to install the
> > software is through the 'kamel' CLI, that pulls the docker image on the
> > cloud system, under the hood. So there's no way a user can mistakenly
> take
> > a docker image for an official release and use it (that was the main
> > concern of the legal discussion you've linked). Same holds also for
> > snapshots.
> >
> > For us, Docker Hub is not a distribution channel, it's a delivery network
> > used internally by the software.
> > If you agree on this, we have good chances to convince the legal team.
> >
> > Continuing this thread, I'd like to simplify a bit the release process,
> to
> > avoid having two votes for runtime and go binaries, because Camel k is a
> > single project, even if split into two repos.
> > I think it makes sense NOT to vote for camel-k-runtime. If we need to
> > release a new camel-k-runtime version, we can do it when we're ready to
> cut
> > a full camel-k release. In this case we stage the camel-k-runtime plus
> the
> > go binaries and docker images (...) and ask for a combined vote.
> > There can be cases where we won't need to release a new runtime but only
> a
> > new version of the binaries and related docker images. In such cases,
> we'll
> > vote only for the camel-k go stuff.
> >
> > As last step, I'd like to keep the release page on GitHub as additional
> > downstream convenience distribution channel. It seems allowed by legal,
> as
> > long as it's used as additional distribution channel and does not replace
> > the main one.
> >
> > What do you think?
> >
> > Nicola
> >
> >
> > Il gio 16 mag 2019, 02:14 Willem Jiang <wi...@gmail.com> ha
> scritto:
> >
> > > For the go artifacts(source and binary) we can put them into [1].
> > > Current ServiceComb service-center is using [2] as the staging repo.
> > > I found camel-k already use publish the dock image here[3], but
> > > according to [4], we cannot use this repo to distribute SNAPSHOT
> > > version.
> > >
> > > So I think the missing parts of current camel-k release are
> > > 1. We need to stage go artifacts and vote of them.
> > > 2. Publish the artifacts if the vote is passed.
> > > 3. Updating the Apache Camel website for the downloading of the
> artifacts.
> > > 4. Push the convicen binary docker image which is based on the
> > > official release.
> > >
> > > FYI, there are some discussion[5] in the Zipkin about the release
> > > which we take as a reference.
> > >
> > > [1]https://dist.apache.org/repos/dist/dev/camel/camel-k
> > > [2]
> > >
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-service-center/
> > > [3]https://hub.docker.com/r/apache/camel-k
> > > [4]https://issues.apache.org/jira/browse/INFRA-12659
> > > [5]https://github.com/apache/incubator-zipkin/issues/2597
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Sat, May 4, 2019 at 3:46 PM Nicola Ferraro <ni...@gmail.com>
> > > wrote:
> > > >
> > > > Yes, released go binaries are still unofficial dev builds. We should
> > > find a
> > > > way to complete the release process.
> > > > There are many points that we need to cover, including signing and
> > > > distributing binaries but also the docker images. Iirc docker hub is
> not
> > > an
> > > > officially recognized system for distributing resources.
> > > >
> > > > But I agree we should standardize the process, otherwise we cannot
> even
> > > do
> > > > official announcements and people won't know about them.
> > > >
> > > > Nicola
> > > >
> > > >
> > > >
> > > > Il sab 4 mag 2019, 09:07 Andrea Cosentino <an...@gmail.com> ha
> > > scritto:
> > > >
> > > > > Ok. Lets synch with others and we can write up a release process
> for
> > > that
> > > > >
> > > > > Il sab 4 mag 2019, 08:56 Willem Jiang <wi...@gmail.com> ha
> > > scritto:
> > > > >
> > > > > > We could use the https://dist.apache.org/repos/dist/dev as a
> > > staging
> > > > > > repo to host the artifacts which need to be voted.
> > > > > >
> > > > > > Willem Jiang
> > > > > >
> > > > > > Twitter: willemjiang
> > > > > > Weibo: 姜宁willem
> > > > > >
> > > > > > On Sat, May 4, 2019 at 2:11 PM Andrea Cosentino <
> ancosen@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > We can add a goal to push the binary generated on dist. But
> all the
> > > > > stuff
> > > > > > > generated is just go binaries and docker images. It's not like
> a
> > > normal
> > > > > > > Java project.
> > > > > > >
> > > > > > > Lets wait for Nicola and Luca about this.
> > > > > > >
> > > > > > > Il sab 4 mag 2019, 03:41 Willem Jiang <wi...@gmail.com>
> ha
> > > > > > scritto:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I just found there are release in the github of camel-k 0.3.3
> > > > > > > > recently. I can only find the vote of camel-k runtime 0.3.3.
> > > From my
> > > > > > > > understanding camel-k is dependent on camel-k runtime, but
> they
> > > are
> > > > > > > > two different projects. As the official Apache release, we
> need
> > > the
> > > > > > > > vote of PMC[1]
> > > > > > > > According to the release distribution guild of ASF[2].
> > > > > > > > "The Apache infrastructure must be the primary source for all
> > > > > > > > artifacts officially released by the ASF." We need to put
> the
> > > > > > > > artifacts of camel-k into the
> > > https://dist.apache.org/repos/dist/.
> > > > > > > >
> > > > > > > > Please let me know if I missed something.
> > > > > > > >
> > > > > > > > [1]http://www.apache.org/dev/release-publishing.html#goal
> > > > > > > > [2]
> > > http://www.apache.org/dev/release-publishing.html#distribution
> > > > > > > >
> > > > > > > > Willem Jiang
> > > > > > > >
> > > > > > > > Twitter: willemjiang
> > > > > > > > Weibo: 姜宁willem
> > > > > > > >
> > > > > >
> > > > >
> > >
>
Re: Release Camel-K 0.3.3
Posted by Willem Jiang <wi...@gmail.com>.
Hi Nicola,
+1 to cut the camel-k release once to simplify the release process.
I think we could create an internal account in the docker hub for the
staging release and publish the snapshot version for internal
validation.
Once we have the official source release, we could push the voted
staging image into Apache docker repo as the final release process.
For the Github release page, it could be better to have one entry
(Apache official link) for the user to download. In this way the user
could not be confused to find out which binary is the best one.
Regards,
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Fri, May 17, 2019 at 6:55 AM Nicola Ferraro <ni...@gmail.com> wrote:
>
> Thanks Willem for taking time for looking into this issue.
>
> For staging the binary files, I think it's ok to follow the ServiceComb
> approach (I assume that the /dev path is for dev builds only and cannot be
> mistaken for the official release path).
> Also point 3 can be addressed. I hope we can do it with the new website,
> that I'd like to see online soon.
>
> But I think we have a problem with docker images. In other projects, docker
> images are a different way of packaging the binaries, but camel k is a
> cloud platform and cannot be run without the docker images.
> This means that if we don't publish the docker images, we're not able to
> test the software before the vote.
>
> So we are asked to release docker images after voting, but cannot vote
> without them. It's a kind of chicken and eggs problem.
>
> On the other side. For camel k, users are not expected to look into docker
> hub to find the software, i.e. we're not using docker hub as a portal to
> distribute the software to our users. The primary way to install the
> software is through the 'kamel' CLI, that pulls the docker image on the
> cloud system, under the hood. So there's no way a user can mistakenly take
> a docker image for an official release and use it (that was the main
> concern of the legal discussion you've linked). Same holds also for
> snapshots.
>
> For us, Docker Hub is not a distribution channel, it's a delivery network
> used internally by the software.
> If you agree on this, we have good chances to convince the legal team.
>
> Continuing this thread, I'd like to simplify a bit the release process, to
> avoid having two votes for runtime and go binaries, because Camel k is a
> single project, even if split into two repos.
> I think it makes sense NOT to vote for camel-k-runtime. If we need to
> release a new camel-k-runtime version, we can do it when we're ready to cut
> a full camel-k release. In this case we stage the camel-k-runtime plus the
> go binaries and docker images (...) and ask for a combined vote.
> There can be cases where we won't need to release a new runtime but only a
> new version of the binaries and related docker images. In such cases, we'll
> vote only for the camel-k go stuff.
>
> As last step, I'd like to keep the release page on GitHub as additional
> downstream convenience distribution channel. It seems allowed by legal, as
> long as it's used as additional distribution channel and does not replace
> the main one.
>
> What do you think?
>
> Nicola
>
>
> Il gio 16 mag 2019, 02:14 Willem Jiang <wi...@gmail.com> ha scritto:
>
> > For the go artifacts(source and binary) we can put them into [1].
> > Current ServiceComb service-center is using [2] as the staging repo.
> > I found camel-k already use publish the dock image here[3], but
> > according to [4], we cannot use this repo to distribute SNAPSHOT
> > version.
> >
> > So I think the missing parts of current camel-k release are
> > 1. We need to stage go artifacts and vote of them.
> > 2. Publish the artifacts if the vote is passed.
> > 3. Updating the Apache Camel website for the downloading of the artifacts.
> > 4. Push the convicen binary docker image which is based on the
> > official release.
> >
> > FYI, there are some discussion[5] in the Zipkin about the release
> > which we take as a reference.
> >
> > [1]https://dist.apache.org/repos/dist/dev/camel/camel-k
> > [2]
> > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-service-center/
> > [3]https://hub.docker.com/r/apache/camel-k
> > [4]https://issues.apache.org/jira/browse/INFRA-12659
> > [5]https://github.com/apache/incubator-zipkin/issues/2597
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Sat, May 4, 2019 at 3:46 PM Nicola Ferraro <ni...@gmail.com>
> > wrote:
> > >
> > > Yes, released go binaries are still unofficial dev builds. We should
> > find a
> > > way to complete the release process.
> > > There are many points that we need to cover, including signing and
> > > distributing binaries but also the docker images. Iirc docker hub is not
> > an
> > > officially recognized system for distributing resources.
> > >
> > > But I agree we should standardize the process, otherwise we cannot even
> > do
> > > official announcements and people won't know about them.
> > >
> > > Nicola
> > >
> > >
> > >
> > > Il sab 4 mag 2019, 09:07 Andrea Cosentino <an...@gmail.com> ha
> > scritto:
> > >
> > > > Ok. Lets synch with others and we can write up a release process for
> > that
> > > >
> > > > Il sab 4 mag 2019, 08:56 Willem Jiang <wi...@gmail.com> ha
> > scritto:
> > > >
> > > > > We could use the https://dist.apache.org/repos/dist/dev as a
> > staging
> > > > > repo to host the artifacts which need to be voted.
> > > > >
> > > > > Willem Jiang
> > > > >
> > > > > Twitter: willemjiang
> > > > > Weibo: 姜宁willem
> > > > >
> > > > > On Sat, May 4, 2019 at 2:11 PM Andrea Cosentino <an...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > We can add a goal to push the binary generated on dist. But all the
> > > > stuff
> > > > > > generated is just go binaries and docker images. It's not like a
> > normal
> > > > > > Java project.
> > > > > >
> > > > > > Lets wait for Nicola and Luca about this.
> > > > > >
> > > > > > Il sab 4 mag 2019, 03:41 Willem Jiang <wi...@gmail.com> ha
> > > > > scritto:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I just found there are release in the github of camel-k 0.3.3
> > > > > > > recently. I can only find the vote of camel-k runtime 0.3.3.
> > From my
> > > > > > > understanding camel-k is dependent on camel-k runtime, but they
> > are
> > > > > > > two different projects. As the official Apache release, we need
> > the
> > > > > > > vote of PMC[1]
> > > > > > > According to the release distribution guild of ASF[2].
> > > > > > > "The Apache infrastructure must be the primary source for all
> > > > > > > artifacts officially released by the ASF." We need to put the
> > > > > > > artifacts of camel-k into the
> > https://dist.apache.org/repos/dist/.
> > > > > > >
> > > > > > > Please let me know if I missed something.
> > > > > > >
> > > > > > > [1]http://www.apache.org/dev/release-publishing.html#goal
> > > > > > > [2]
> > http://www.apache.org/dev/release-publishing.html#distribution
> > > > > > >
> > > > > > > Willem Jiang
> > > > > > >
> > > > > > > Twitter: willemjiang
> > > > > > > Weibo: 姜宁willem
> > > > > > >
> > > > >
> > > >
> >
Re: Release Camel-K 0.3.3
Posted by Nicola Ferraro <ni...@gmail.com>.
Thanks Willem for taking time for looking into this issue.
For staging the binary files, I think it's ok to follow the ServiceComb
approach (I assume that the /dev path is for dev builds only and cannot be
mistaken for the official release path).
Also point 3 can be addressed. I hope we can do it with the new website,
that I'd like to see online soon.
But I think we have a problem with docker images. In other projects, docker
images are a different way of packaging the binaries, but camel k is a
cloud platform and cannot be run without the docker images.
This means that if we don't publish the docker images, we're not able to
test the software before the vote.
So we are asked to release docker images after voting, but cannot vote
without them. It's a kind of chicken and eggs problem.
On the other side. For camel k, users are not expected to look into docker
hub to find the software, i.e. we're not using docker hub as a portal to
distribute the software to our users. The primary way to install the
software is through the 'kamel' CLI, that pulls the docker image on the
cloud system, under the hood. So there's no way a user can mistakenly take
a docker image for an official release and use it (that was the main
concern of the legal discussion you've linked). Same holds also for
snapshots.
For us, Docker Hub is not a distribution channel, it's a delivery network
used internally by the software.
If you agree on this, we have good chances to convince the legal team.
Continuing this thread, I'd like to simplify a bit the release process, to
avoid having two votes for runtime and go binaries, because Camel k is a
single project, even if split into two repos.
I think it makes sense NOT to vote for camel-k-runtime. If we need to
release a new camel-k-runtime version, we can do it when we're ready to cut
a full camel-k release. In this case we stage the camel-k-runtime plus the
go binaries and docker images (...) and ask for a combined vote.
There can be cases where we won't need to release a new runtime but only a
new version of the binaries and related docker images. In such cases, we'll
vote only for the camel-k go stuff.
As last step, I'd like to keep the release page on GitHub as additional
downstream convenience distribution channel. It seems allowed by legal, as
long as it's used as additional distribution channel and does not replace
the main one.
What do you think?
Nicola
Il gio 16 mag 2019, 02:14 Willem Jiang <wi...@gmail.com> ha scritto:
> For the go artifacts(source and binary) we can put them into [1].
> Current ServiceComb service-center is using [2] as the staging repo.
> I found camel-k already use publish the dock image here[3], but
> according to [4], we cannot use this repo to distribute SNAPSHOT
> version.
>
> So I think the missing parts of current camel-k release are
> 1. We need to stage go artifacts and vote of them.
> 2. Publish the artifacts if the vote is passed.
> 3. Updating the Apache Camel website for the downloading of the artifacts.
> 4. Push the convicen binary docker image which is based on the
> official release.
>
> FYI, there are some discussion[5] in the Zipkin about the release
> which we take as a reference.
>
> [1]https://dist.apache.org/repos/dist/dev/camel/camel-k
> [2]
> https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-service-center/
> [3]https://hub.docker.com/r/apache/camel-k
> [4]https://issues.apache.org/jira/browse/INFRA-12659
> [5]https://github.com/apache/incubator-zipkin/issues/2597
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, May 4, 2019 at 3:46 PM Nicola Ferraro <ni...@gmail.com>
> wrote:
> >
> > Yes, released go binaries are still unofficial dev builds. We should
> find a
> > way to complete the release process.
> > There are many points that we need to cover, including signing and
> > distributing binaries but also the docker images. Iirc docker hub is not
> an
> > officially recognized system for distributing resources.
> >
> > But I agree we should standardize the process, otherwise we cannot even
> do
> > official announcements and people won't know about them.
> >
> > Nicola
> >
> >
> >
> > Il sab 4 mag 2019, 09:07 Andrea Cosentino <an...@gmail.com> ha
> scritto:
> >
> > > Ok. Lets synch with others and we can write up a release process for
> that
> > >
> > > Il sab 4 mag 2019, 08:56 Willem Jiang <wi...@gmail.com> ha
> scritto:
> > >
> > > > We could use the https://dist.apache.org/repos/dist/dev as a
> staging
> > > > repo to host the artifacts which need to be voted.
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> > > > On Sat, May 4, 2019 at 2:11 PM Andrea Cosentino <an...@gmail.com>
> > > wrote:
> > > > >
> > > > > We can add a goal to push the binary generated on dist. But all the
> > > stuff
> > > > > generated is just go binaries and docker images. It's not like a
> normal
> > > > > Java project.
> > > > >
> > > > > Lets wait for Nicola and Luca about this.
> > > > >
> > > > > Il sab 4 mag 2019, 03:41 Willem Jiang <wi...@gmail.com> ha
> > > > scritto:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I just found there are release in the github of camel-k 0.3.3
> > > > > > recently. I can only find the vote of camel-k runtime 0.3.3.
> From my
> > > > > > understanding camel-k is dependent on camel-k runtime, but they
> are
> > > > > > two different projects. As the official Apache release, we need
> the
> > > > > > vote of PMC[1]
> > > > > > According to the release distribution guild of ASF[2].
> > > > > > "The Apache infrastructure must be the primary source for all
> > > > > > artifacts officially released by the ASF." We need to put the
> > > > > > artifacts of camel-k into the
> https://dist.apache.org/repos/dist/.
> > > > > >
> > > > > > Please let me know if I missed something.
> > > > > >
> > > > > > [1]http://www.apache.org/dev/release-publishing.html#goal
> > > > > > [2]
> http://www.apache.org/dev/release-publishing.html#distribution
> > > > > >
> > > > > > Willem Jiang
> > > > > >
> > > > > > Twitter: willemjiang
> > > > > > Weibo: 姜宁willem
> > > > > >
> > > >
> > >
>
Re: Release Camel-K 0.3.3
Posted by Willem Jiang <wi...@gmail.com>.
For the go artifacts(source and binary) we can put them into [1].
Current ServiceComb service-center is using [2] as the staging repo.
I found camel-k already use publish the dock image here[3], but
according to [4], we cannot use this repo to distribute SNAPSHOT
version.
So I think the missing parts of current camel-k release are
1. We need to stage go artifacts and vote of them.
2. Publish the artifacts if the vote is passed.
3. Updating the Apache Camel website for the downloading of the artifacts.
4. Push the convicen binary docker image which is based on the
official release.
FYI, there are some discussion[5] in the Zipkin about the release
which we take as a reference.
[1]https://dist.apache.org/repos/dist/dev/camel/camel-k
[2]https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-service-center/
[3]https://hub.docker.com/r/apache/camel-k
[4]https://issues.apache.org/jira/browse/INFRA-12659
[5]https://github.com/apache/incubator-zipkin/issues/2597
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Sat, May 4, 2019 at 3:46 PM Nicola Ferraro <ni...@gmail.com> wrote:
>
> Yes, released go binaries are still unofficial dev builds. We should find a
> way to complete the release process.
> There are many points that we need to cover, including signing and
> distributing binaries but also the docker images. Iirc docker hub is not an
> officially recognized system for distributing resources.
>
> But I agree we should standardize the process, otherwise we cannot even do
> official announcements and people won't know about them.
>
> Nicola
>
>
>
> Il sab 4 mag 2019, 09:07 Andrea Cosentino <an...@gmail.com> ha scritto:
>
> > Ok. Lets synch with others and we can write up a release process for that
> >
> > Il sab 4 mag 2019, 08:56 Willem Jiang <wi...@gmail.com> ha scritto:
> >
> > > We could use the https://dist.apache.org/repos/dist/dev as a staging
> > > repo to host the artifacts which need to be voted.
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Sat, May 4, 2019 at 2:11 PM Andrea Cosentino <an...@gmail.com>
> > wrote:
> > > >
> > > > We can add a goal to push the binary generated on dist. But all the
> > stuff
> > > > generated is just go binaries and docker images. It's not like a normal
> > > > Java project.
> > > >
> > > > Lets wait for Nicola and Luca about this.
> > > >
> > > > Il sab 4 mag 2019, 03:41 Willem Jiang <wi...@gmail.com> ha
> > > scritto:
> > > >
> > > > > Hi,
> > > > >
> > > > > I just found there are release in the github of camel-k 0.3.3
> > > > > recently. I can only find the vote of camel-k runtime 0.3.3. From my
> > > > > understanding camel-k is dependent on camel-k runtime, but they are
> > > > > two different projects. As the official Apache release, we need the
> > > > > vote of PMC[1]
> > > > > According to the release distribution guild of ASF[2].
> > > > > "The Apache infrastructure must be the primary source for all
> > > > > artifacts officially released by the ASF." We need to put the
> > > > > artifacts of camel-k into the https://dist.apache.org/repos/dist/.
> > > > >
> > > > > Please let me know if I missed something.
> > > > >
> > > > > [1]http://www.apache.org/dev/release-publishing.html#goal
> > > > > [2]http://www.apache.org/dev/release-publishing.html#distribution
> > > > >
> > > > > Willem Jiang
> > > > >
> > > > > Twitter: willemjiang
> > > > > Weibo: 姜宁willem
> > > > >
> > >
> >
Re: Release Camel-K 0.3.3
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, May 4, 2019 at 9:46 AM Nicola Ferraro <ni...@gmail.com> wrote:
>
> Yes, released go binaries are still unofficial dev builds. We should find a
> way to complete the release process.
> There are many points that we need to cover, including signing and
> distributing binaries but also the docker images. Iirc docker hub is not an
> officially recognized system for distributing resources.
>
> But I agree we should standardize the process, otherwise we cannot even do
> official announcements and people won't know about them.
>
Yeah we have time until Apache Camel K 1.0 GA to find the process.
There must be other Apache projects that has docker images and signing
of native binaries etc.
But there is also the recent announcement about Apache and github
which maybe can make the release process easier.
> Nicola
>
>
>
> Il sab 4 mag 2019, 09:07 Andrea Cosentino <an...@gmail.com> ha scritto:
>
> > Ok. Lets synch with others and we can write up a release process for that
> >
> > Il sab 4 mag 2019, 08:56 Willem Jiang <wi...@gmail.com> ha scritto:
> >
> > > We could use the https://dist.apache.org/repos/dist/dev as a staging
> > > repo to host the artifacts which need to be voted.
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Sat, May 4, 2019 at 2:11 PM Andrea Cosentino <an...@gmail.com>
> > wrote:
> > > >
> > > > We can add a goal to push the binary generated on dist. But all the
> > stuff
> > > > generated is just go binaries and docker images. It's not like a normal
> > > > Java project.
> > > >
> > > > Lets wait for Nicola and Luca about this.
> > > >
> > > > Il sab 4 mag 2019, 03:41 Willem Jiang <wi...@gmail.com> ha
> > > scritto:
> > > >
> > > > > Hi,
> > > > >
> > > > > I just found there are release in the github of camel-k 0.3.3
> > > > > recently. I can only find the vote of camel-k runtime 0.3.3. From my
> > > > > understanding camel-k is dependent on camel-k runtime, but they are
> > > > > two different projects. As the official Apache release, we need the
> > > > > vote of PMC[1]
> > > > > According to the release distribution guild of ASF[2].
> > > > > "The Apache infrastructure must be the primary source for all
> > > > > artifacts officially released by the ASF." We need to put the
> > > > > artifacts of camel-k into the https://dist.apache.org/repos/dist/.
> > > > >
> > > > > Please let me know if I missed something.
> > > > >
> > > > > [1]http://www.apache.org/dev/release-publishing.html#goal
> > > > > [2]http://www.apache.org/dev/release-publishing.html#distribution
> > > > >
> > > > > Willem Jiang
> > > > >
> > > > > Twitter: willemjiang
> > > > > Weibo: 姜宁willem
> > > > >
> > >
> >
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Release Camel-K 0.3.3
Posted by Nicola Ferraro <ni...@gmail.com>.
Yes, released go binaries are still unofficial dev builds. We should find a
way to complete the release process.
There are many points that we need to cover, including signing and
distributing binaries but also the docker images. Iirc docker hub is not an
officially recognized system for distributing resources.
But I agree we should standardize the process, otherwise we cannot even do
official announcements and people won't know about them.
Nicola
Il sab 4 mag 2019, 09:07 Andrea Cosentino <an...@gmail.com> ha scritto:
> Ok. Lets synch with others and we can write up a release process for that
>
> Il sab 4 mag 2019, 08:56 Willem Jiang <wi...@gmail.com> ha scritto:
>
> > We could use the https://dist.apache.org/repos/dist/dev as a staging
> > repo to host the artifacts which need to be voted.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Sat, May 4, 2019 at 2:11 PM Andrea Cosentino <an...@gmail.com>
> wrote:
> > >
> > > We can add a goal to push the binary generated on dist. But all the
> stuff
> > > generated is just go binaries and docker images. It's not like a normal
> > > Java project.
> > >
> > > Lets wait for Nicola and Luca about this.
> > >
> > > Il sab 4 mag 2019, 03:41 Willem Jiang <wi...@gmail.com> ha
> > scritto:
> > >
> > > > Hi,
> > > >
> > > > I just found there are release in the github of camel-k 0.3.3
> > > > recently. I can only find the vote of camel-k runtime 0.3.3. From my
> > > > understanding camel-k is dependent on camel-k runtime, but they are
> > > > two different projects. As the official Apache release, we need the
> > > > vote of PMC[1]
> > > > According to the release distribution guild of ASF[2].
> > > > "The Apache infrastructure must be the primary source for all
> > > > artifacts officially released by the ASF." We need to put the
> > > > artifacts of camel-k into the https://dist.apache.org/repos/dist/.
> > > >
> > > > Please let me know if I missed something.
> > > >
> > > > [1]http://www.apache.org/dev/release-publishing.html#goal
> > > > [2]http://www.apache.org/dev/release-publishing.html#distribution
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> >
>
Re: Release Camel-K 0.3.3
Posted by Andrea Cosentino <an...@gmail.com>.
Ok. Lets synch with others and we can write up a release process for that
Il sab 4 mag 2019, 08:56 Willem Jiang <wi...@gmail.com> ha scritto:
> We could use the https://dist.apache.org/repos/dist/dev as a staging
> repo to host the artifacts which need to be voted.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, May 4, 2019 at 2:11 PM Andrea Cosentino <an...@gmail.com> wrote:
> >
> > We can add a goal to push the binary generated on dist. But all the stuff
> > generated is just go binaries and docker images. It's not like a normal
> > Java project.
> >
> > Lets wait for Nicola and Luca about this.
> >
> > Il sab 4 mag 2019, 03:41 Willem Jiang <wi...@gmail.com> ha
> scritto:
> >
> > > Hi,
> > >
> > > I just found there are release in the github of camel-k 0.3.3
> > > recently. I can only find the vote of camel-k runtime 0.3.3. From my
> > > understanding camel-k is dependent on camel-k runtime, but they are
> > > two different projects. As the official Apache release, we need the
> > > vote of PMC[1]
> > > According to the release distribution guild of ASF[2].
> > > "The Apache infrastructure must be the primary source for all
> > > artifacts officially released by the ASF." We need to put the
> > > artifacts of camel-k into the https://dist.apache.org/repos/dist/.
> > >
> > > Please let me know if I missed something.
> > >
> > > [1]http://www.apache.org/dev/release-publishing.html#goal
> > > [2]http://www.apache.org/dev/release-publishing.html#distribution
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
>
Re: Release Camel-K 0.3.3
Posted by Willem Jiang <wi...@gmail.com>.
We could use the https://dist.apache.org/repos/dist/dev as a staging
repo to host the artifacts which need to be voted.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Sat, May 4, 2019 at 2:11 PM Andrea Cosentino <an...@gmail.com> wrote:
>
> We can add a goal to push the binary generated on dist. But all the stuff
> generated is just go binaries and docker images. It's not like a normal
> Java project.
>
> Lets wait for Nicola and Luca about this.
>
> Il sab 4 mag 2019, 03:41 Willem Jiang <wi...@gmail.com> ha scritto:
>
> > Hi,
> >
> > I just found there are release in the github of camel-k 0.3.3
> > recently. I can only find the vote of camel-k runtime 0.3.3. From my
> > understanding camel-k is dependent on camel-k runtime, but they are
> > two different projects. As the official Apache release, we need the
> > vote of PMC[1]
> > According to the release distribution guild of ASF[2].
> > "The Apache infrastructure must be the primary source for all
> > artifacts officially released by the ASF." We need to put the
> > artifacts of camel-k into the https://dist.apache.org/repos/dist/.
> >
> > Please let me know if I missed something.
> >
> > [1]http://www.apache.org/dev/release-publishing.html#goal
> > [2]http://www.apache.org/dev/release-publishing.html#distribution
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
Re: Release Camel-K 0.3.3
Posted by Andrea Cosentino <an...@gmail.com>.
We can add a goal to push the binary generated on dist. But all the stuff
generated is just go binaries and docker images. It's not like a normal
Java project.
Lets wait for Nicola and Luca about this.
Il sab 4 mag 2019, 03:41 Willem Jiang <wi...@gmail.com> ha scritto:
> Hi,
>
> I just found there are release in the github of camel-k 0.3.3
> recently. I can only find the vote of camel-k runtime 0.3.3. From my
> understanding camel-k is dependent on camel-k runtime, but they are
> two different projects. As the official Apache release, we need the
> vote of PMC[1]
> According to the release distribution guild of ASF[2].
> "The Apache infrastructure must be the primary source for all
> artifacts officially released by the ASF." We need to put the
> artifacts of camel-k into the https://dist.apache.org/repos/dist/.
>
> Please let me know if I missed something.
>
> [1]http://www.apache.org/dev/release-publishing.html#goal
> [2]http://www.apache.org/dev/release-publishing.html#distribution
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>