You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kie.apache.org by Tibor Zimányi <tz...@apache.org> on 2024/03/15 14:44:36 UTC
[HEADS-UP] Summarizing the release process
Hi everyone,
at the meeting, there was a need raised, to summarize what happens when we
will be ready for a release.
Before we get to building the actual release, we need to hold a vote about
doing a release. If the vote passes, we can continue and start building the
release. If there are objections to doing the release, people objecting to
the release need to properly raise feedback and proposals about the
problems they have with the release, so we can discuss or/and address them.
Our release will need to be done semi-automatic. We have a set of release
pipelines that need to be run in a series. The overall process is expected
to be as follows:
- runtimes release pipelines executed (1) - These pipelines will build all
runtime libraries (e.g. from drools, kogito-runtimes, optaplanner, etc.
repositories) and deploy the libraries to a staging environment in Maven
Central. The document linked may need adjustments as we never did a release
yet with the new CI in Apache.
- The runtime libraries pipelines need to deploy the libraries also to an
environment, from which the UI build (kie-tools and other related
repositories) can consume them. It could be e.g. Apache Nexus, where we
currently deploy build artifacts from the nightly builds.
- UI release pipelines are executed (2). They deploy the build artifacts to
the staging environment.
- Images and other remaining release pipelines are executed. The built
images and other remaining release artifacts are deployed to a staging
environment.
When we have all required artifacts prepared in the staging environments,
we need to ask the Incubator IPMC members to have a vote about our release.
They will provide feedback to us and cast a vote. If they approve the
release, we will publish the artifacts from the staging environments to the
public ones. If they don't approve the release, we need to fix the release
based on their feedback and do it again from the start. More information
about the release process and requirements in Apache can be found in the
following links (3) (4).
This is a work in progress summary, so if someone knows more about the
release process, or something needs to be corrected or added, please reply
to this thread.
Best regards,
Tibor
(1)
https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/docs/release%20pipeline.md
(2)
https://github.com/apache/incubator-kie-tools/blob/main/RELEASE_PROCESS.md
(3) https://www.apache.org/legal/release-policy.html
(4) https://infra.apache.org/release-publishing.html
Re: [HEADS-UP] Summarizing the release process
Posted by Jason Porter <li...@apache.org>.
This is pretty much correct.
I fully expect we'll get some -1s at the IPMC level. The question is going to be if it stops us from actually doing a release.
What I suggest we do is once we're ready, we create a 10.0.0 branch and tag that as RC1. If there are things we'll need to do to address -1s from the IPMC we work on those, get ready (we shouldn't have to have another 72 vote after this within the project) to build another release, tag that as RC2, send it back to the IPMC and repeat until we have more +1 than -1. At which point we tag that RC as Final, or drop the RC, whichever versioning scheme we're following, and cut our release.
On 2024/03/15 16:17:12 Tiago Bento wrote:
> Tibor,
>
> Thanks for starting this more in-depth talk about the actual release
> process for Apache KIE 10.
>
> If we end up agreeing on the proposal to unblock Apache KIE 10 stated
> here [1], there will be no "Images and other remaining release
> pipelines" to execute after `kie-tools`. The `kogito-images` repo will
> be built/released as part of the "runtimes" pipelines.
> `kogito-swf-{builder,devmode}` images and the
> `kogito-serverless-operator` repo will be inside `kie-tools`, so they
> will be built/released as part of it.
>
> To make things a little bit more complicated (sorry), I think for us
> to even call a vote, we need to be able to:
>
> 1. Clone all Apache KIE repos pointing to a Git ref (E.g., 10.0.x).
> 2. Build all Apache KIE repos, in an order we define, running the
> specified build commands for each one of them.
>
> Of course, I think we can use our automated pipelines to produce a
> staging environment that we can use to check if everything is working
> before calling the vote for the release.
>
> If I understood correctly, people need to be able to download and
> build the proposed release themselves, though, not only relying on our
> CI pipelines. If that's the case (please correct me if I'm wrong,
> Jason!), our job then would be to describe:
>
> A. The build environment.
> B. Build commands for each repo individually.
> C. The order in which repos should be built.
>
> Once we have the instructions clear and those two requirements
> satisfied, then we're able to call a vote. When approved, we can
> proceed to pushing tags to Git (E.g., 10.0.0), and building it using
> our pipelines to publish artifacts where they belong.
>
> From what I understood, at least, once we call the vote and the
> release is approved, we can't make changes to the Git ref initially
> shared.
>
> With that said, I'd love it if we could discuss it a little more, as
> my current understanding of the process slightly differs from the one
> you shared.
>
> Regards,
>
> Tiago Bento
>
> [1] https://lists.apache.org/thread/58xm7pqdyztf7qztmhvntf8wdmvfx7jx
>
> On Fri, Mar 15, 2024 at 10:44 AM Tibor Zimányi <tz...@apache.org> wrote:
> >
> > Hi everyone,
> >
> > at the meeting, there was a need raised, to summarize what happens when we
> > will be ready for a release.
> >
> > Before we get to building the actual release, we need to hold a vote about
> > doing a release. If the vote passes, we can continue and start building the
> > release. If there are objections to doing the release, people objecting to
> > the release need to properly raise feedback and proposals about the
> > problems they have with the release, so we can discuss or/and address them.
> >
> > Our release will need to be done semi-automatic. We have a set of release
> > pipelines that need to be run in a series. The overall process is expected
> > to be as follows:
> >
> > - runtimes release pipelines executed (1) - These pipelines will build all
> > runtime libraries (e.g. from drools, kogito-runtimes, optaplanner, etc.
> > repositories) and deploy the libraries to a staging environment in Maven
> > Central. The document linked may need adjustments as we never did a release
> > yet with the new CI in Apache.
> > - The runtime libraries pipelines need to deploy the libraries also to an
> > environment, from which the UI build (kie-tools and other related
> > repositories) can consume them. It could be e.g. Apache Nexus, where we
> > currently deploy build artifacts from the nightly builds.
> > - UI release pipelines are executed (2). They deploy the build artifacts to
> > the staging environment.
> > - Images and other remaining release pipelines are executed. The built
> > images and other remaining release artifacts are deployed to a staging
> > environment.
> >
> > When we have all required artifacts prepared in the staging environments,
> > we need to ask the Incubator IPMC members to have a vote about our release.
> > They will provide feedback to us and cast a vote. If they approve the
> > release, we will publish the artifacts from the staging environments to the
> > public ones. If they don't approve the release, we need to fix the release
> > based on their feedback and do it again from the start. More information
> > about the release process and requirements in Apache can be found in the
> > following links (3) (4).
> >
> > This is a work in progress summary, so if someone knows more about the
> > release process, or something needs to be corrected or added, please reply
> > to this thread.
> >
> > Best regards,
> > Tibor
> >
> > (1)
> > https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/docs/release%20pipeline.md
> > (2)
> > https://github.com/apache/incubator-kie-tools/blob/main/RELEASE_PROCESS.md
> > (3) https://www.apache.org/legal/release-policy.html
> > (4) https://infra.apache.org/release-publishing.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
> For additional commands, e-mail: dev-help@kie.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org
Re: [HEADS-UP] Summarizing the release process
Posted by Tiago Bento <ti...@apache.org>.
Tibor,
Thanks for starting this more in-depth talk about the actual release
process for Apache KIE 10.
If we end up agreeing on the proposal to unblock Apache KIE 10 stated
here [1], there will be no "Images and other remaining release
pipelines" to execute after `kie-tools`. The `kogito-images` repo will
be built/released as part of the "runtimes" pipelines.
`kogito-swf-{builder,devmode}` images and the
`kogito-serverless-operator` repo will be inside `kie-tools`, so they
will be built/released as part of it.
To make things a little bit more complicated (sorry), I think for us
to even call a vote, we need to be able to:
1. Clone all Apache KIE repos pointing to a Git ref (E.g., 10.0.x).
2. Build all Apache KIE repos, in an order we define, running the
specified build commands for each one of them.
Of course, I think we can use our automated pipelines to produce a
staging environment that we can use to check if everything is working
before calling the vote for the release.
If I understood correctly, people need to be able to download and
build the proposed release themselves, though, not only relying on our
CI pipelines. If that's the case (please correct me if I'm wrong,
Jason!), our job then would be to describe:
A. The build environment.
B. Build commands for each repo individually.
C. The order in which repos should be built.
Once we have the instructions clear and those two requirements
satisfied, then we're able to call a vote. When approved, we can
proceed to pushing tags to Git (E.g., 10.0.0), and building it using
our pipelines to publish artifacts where they belong.
From what I understood, at least, once we call the vote and the
release is approved, we can't make changes to the Git ref initially
shared.
With that said, I'd love it if we could discuss it a little more, as
my current understanding of the process slightly differs from the one
you shared.
Regards,
Tiago Bento
[1] https://lists.apache.org/thread/58xm7pqdyztf7qztmhvntf8wdmvfx7jx
On Fri, Mar 15, 2024 at 10:44 AM Tibor Zimányi <tz...@apache.org> wrote:
>
> Hi everyone,
>
> at the meeting, there was a need raised, to summarize what happens when we
> will be ready for a release.
>
> Before we get to building the actual release, we need to hold a vote about
> doing a release. If the vote passes, we can continue and start building the
> release. If there are objections to doing the release, people objecting to
> the release need to properly raise feedback and proposals about the
> problems they have with the release, so we can discuss or/and address them.
>
> Our release will need to be done semi-automatic. We have a set of release
> pipelines that need to be run in a series. The overall process is expected
> to be as follows:
>
> - runtimes release pipelines executed (1) - These pipelines will build all
> runtime libraries (e.g. from drools, kogito-runtimes, optaplanner, etc.
> repositories) and deploy the libraries to a staging environment in Maven
> Central. The document linked may need adjustments as we never did a release
> yet with the new CI in Apache.
> - The runtime libraries pipelines need to deploy the libraries also to an
> environment, from which the UI build (kie-tools and other related
> repositories) can consume them. It could be e.g. Apache Nexus, where we
> currently deploy build artifacts from the nightly builds.
> - UI release pipelines are executed (2). They deploy the build artifacts to
> the staging environment.
> - Images and other remaining release pipelines are executed. The built
> images and other remaining release artifacts are deployed to a staging
> environment.
>
> When we have all required artifacts prepared in the staging environments,
> we need to ask the Incubator IPMC members to have a vote about our release.
> They will provide feedback to us and cast a vote. If they approve the
> release, we will publish the artifacts from the staging environments to the
> public ones. If they don't approve the release, we need to fix the release
> based on their feedback and do it again from the start. More information
> about the release process and requirements in Apache can be found in the
> following links (3) (4).
>
> This is a work in progress summary, so if someone knows more about the
> release process, or something needs to be corrected or added, please reply
> to this thread.
>
> Best regards,
> Tibor
>
> (1)
> https://github.com/apache/incubator-kie-kogito-pipelines/blob/main/docs/release%20pipeline.md
> (2)
> https://github.com/apache/incubator-kie-tools/blob/main/RELEASE_PROCESS.md
> (3) https://www.apache.org/legal/release-policy.html
> (4) https://infra.apache.org/release-publishing.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@kie.apache.org
For additional commands, e-mail: dev-help@kie.apache.org