[DISCUSS] Change to the release cycle

[Wilfred Spiegelenburg <wi...@apache.org>]

Hi all,

While some of us were at CoC we talked about the release cycle.
The current cycle is really short as we branch and start the creation
of the release at almost the same time. This does not leave time to
check if the release is in a decent state.

The proposal is to extend the time that we have between branching and
starting a release.
That will give everyone more time to test the release and check its stability.
From the moment that the branch is created only fixes allowed into the
branch are linked to:
* CVEs
* Stopper bugs
* Backwards compatibility fixes
* Build related fixes
New features and or other minor issues will not be allowed into the
branch. Any fixes made in the branch will follow the normal procedure
of commit into master first and then cherry-pick into the branch.
Committers will need to assess if the change must be backported into
the release branch.

The time between branching and starting the release is flexible. No
fixed time is currently proposed but we probably should set a minimum
one at least. For example, a minimum of 2 or 4 weeks between branching
and starting the release.
After branching some artefacts should be generated for testing. There
are two options:
* source release
* convenience binaries in the form of docker images

Both options are possible. The choice depends on the community's preference.
Whatever is provided will be removed after we start the release voting.
Running a pre-release like this in production is never recommended.

Wilfred

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: dev-help@yunikorn.apache.org

Re: [DISCUSS] Change to the release cycle

[Weiwei Yang <ww...@apache.org>]

Awesome, sounds great!

Thanks!
Weiwei

On Thu, Nov 14, 2024 at 6:03 PM Wilfred Spiegelenburg <wi...@apache.org>
wrote:

> Weiwei,
>
> Yes that is exactly why we need to extend the time between creating
> the branches and the first real release candidate.
> It will allow us to run these kinds of tests, even if it takes
> multiple days to run and analyse them.
>
> You have seen the same issues as we all see and as a community we need
> to do better in this area.
> Wilfred
>
> On Fri, 15 Nov 2024 at 09:56, Weiwei Yang <ww...@apache.org> wrote:
> >
> > Hi Wilfred
> >
> > Recently I had some discussion with Shravan Achar and Junyan Lin, and we
> > are thinking about helping
> > the community to have some sort of pre-release tests, the objective is to
> > run the pre-release builds on a
> > simulated or a real cluster with auto-scaling enabled, run some synthetic
> > workloads, scheduled ones at
> > certain scale, e.g few hundreds to 1k nodes. Use that to validate a
> release
> > if it is ready for production.
> > Would that idea fit into this?
> >
> > Weiwei
> >
> > On Wed, Nov 13, 2024 at 6:57 PM Wilfred Spiegelenburg <
> wilfreds@apache.org>
> > wrote:
> >
> > > Hi all,
> > >
> > > While some of us were at CoC we talked about the release cycle.
> > > The current cycle is really short as we branch and start the creation
> > > of the release at almost the same time. This does not leave time to
> > > check if the release is in a decent state.
> > >
> > > The proposal is to extend the time that we have between branching and
> > > starting a release.
> > > That will give everyone more time to test the release and check its
> > > stability.
> > > From the moment that the branch is created only fixes allowed into the
> > > branch are linked to:
> > > * CVEs
> > > * Stopper bugs
> > > * Backwards compatibility fixes
> > > * Build related fixes
> > > New features and or other minor issues will not be allowed into the
> > > branch. Any fixes made in the branch will follow the normal procedure
> > > of commit into master first and then cherry-pick into the branch.
> > > Committers will need to assess if the change must be backported into
> > > the release branch.
> > >
> > > The time between branching and starting the release is flexible. No
> > > fixed time is currently proposed but we probably should set a minimum
> > > one at least. For example, a minimum of 2 or 4 weeks between branching
> > > and starting the release.
> > > After branching some artefacts should be generated for testing. There
> > > are two options:
> > > * source release
> > > * convenience binaries in the form of docker images
> > >
> > > Both options are possible. The choice depends on the community's
> > > preference.
> > > Whatever is provided will be removed after we start the release voting.
> > > Running a pre-release like this in production is never recommended.
> > >
> > > Wilfred
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@yunikorn.apache.org
> > > For additional commands, e-mail: dev-help@yunikorn.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@yunikorn.apache.org
> For additional commands, e-mail: dev-help@yunikorn.apache.org
>
>

Re: [DISCUSS] Change to the release cycle

[Wilfred Spiegelenburg <wi...@apache.org>]

Weiwei,

Yes that is exactly why we need to extend the time between creating
the branches and the first real release candidate.
It will allow us to run these kinds of tests, even if it takes
multiple days to run and analyse them.

You have seen the same issues as we all see and as a community we need
to do better in this area.
Wilfred

On Fri, 15 Nov 2024 at 09:56, Weiwei Yang <ww...@apache.org> wrote:
>
> Hi Wilfred
>
> Recently I had some discussion with Shravan Achar and Junyan Lin, and we
> are thinking about helping
> the community to have some sort of pre-release tests, the objective is to
> run the pre-release builds on a
> simulated or a real cluster with auto-scaling enabled, run some synthetic
> workloads, scheduled ones at
> certain scale, e.g few hundreds to 1k nodes. Use that to validate a release
> if it is ready for production.
> Would that idea fit into this?
>
> Weiwei
>
> On Wed, Nov 13, 2024 at 6:57 PM Wilfred Spiegelenburg <wi...@apache.org>
> wrote:
>
> > Hi all,
> >
> > While some of us were at CoC we talked about the release cycle.
> > The current cycle is really short as we branch and start the creation
> > of the release at almost the same time. This does not leave time to
> > check if the release is in a decent state.
> >
> > The proposal is to extend the time that we have between branching and
> > starting a release.
> > That will give everyone more time to test the release and check its
> > stability.
> > From the moment that the branch is created only fixes allowed into the
> > branch are linked to:
> > * CVEs
> > * Stopper bugs
> > * Backwards compatibility fixes
> > * Build related fixes
> > New features and or other minor issues will not be allowed into the
> > branch. Any fixes made in the branch will follow the normal procedure
> > of commit into master first and then cherry-pick into the branch.
> > Committers will need to assess if the change must be backported into
> > the release branch.
> >
> > The time between branching and starting the release is flexible. No
> > fixed time is currently proposed but we probably should set a minimum
> > one at least. For example, a minimum of 2 or 4 weeks between branching
> > and starting the release.
> > After branching some artefacts should be generated for testing. There
> > are two options:
> > * source release
> > * convenience binaries in the form of docker images
> >
> > Both options are possible. The choice depends on the community's
> > preference.
> > Whatever is provided will be removed after we start the release voting.
> > Running a pre-release like this in production is never recommended.
> >
> > Wilfred
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@yunikorn.apache.org
> > For additional commands, e-mail: dev-help@yunikorn.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: dev-help@yunikorn.apache.org

Re: [DISCUSS] Change to the release cycle

[Weiwei Yang <ww...@apache.org>]

Hi Wilfred

Recently I had some discussion with Shravan Achar and Junyan Lin, and we
are thinking about helping
the community to have some sort of pre-release tests, the objective is to
run the pre-release builds on a
simulated or a real cluster with auto-scaling enabled, run some synthetic
workloads, scheduled ones at
certain scale, e.g few hundreds to 1k nodes. Use that to validate a release
if it is ready for production.
Would that idea fit into this?

Weiwei

On Wed, Nov 13, 2024 at 6:57 PM Wilfred Spiegelenburg <wi...@apache.org>
wrote:

> Hi all,
>
> While some of us were at CoC we talked about the release cycle.
> The current cycle is really short as we branch and start the creation
> of the release at almost the same time. This does not leave time to
> check if the release is in a decent state.
>
> The proposal is to extend the time that we have between branching and
> starting a release.
> That will give everyone more time to test the release and check its
> stability.
> From the moment that the branch is created only fixes allowed into the
> branch are linked to:
> * CVEs
> * Stopper bugs
> * Backwards compatibility fixes
> * Build related fixes
> New features and or other minor issues will not be allowed into the
> branch. Any fixes made in the branch will follow the normal procedure
> of commit into master first and then cherry-pick into the branch.
> Committers will need to assess if the change must be backported into
> the release branch.
>
> The time between branching and starting the release is flexible. No
> fixed time is currently proposed but we probably should set a minimum
> one at least. For example, a minimum of 2 or 4 weeks between branching
> and starting the release.
> After branching some artefacts should be generated for testing. There
> are two options:
> * source release
> * convenience binaries in the form of docker images
>
> Both options are possible. The choice depends on the community's
> preference.
> Whatever is provided will be removed after we start the release voting.
> Running a pre-release like this in production is never recommended.
>
> Wilfred
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@yunikorn.apache.org
> For additional commands, e-mail: dev-help@yunikorn.apache.org
>
>