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 <[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
