Dominik, In the past, tools, drools, jBPM, etc…. were considered different projects, some (ie tools) with independent release cycle. This has changed when donated to Apache as a single project: Apache KIE. So, in other words: no different release cycles within Apache KIE.
Unfortunately I don’t think we have the maturity within Apache to define LTS, as the goal of incubating is to graduate… and I expect we have in each subsequent release advances towards graduation. It’s also fair to assume that we are having minor releases on each release. As I mentioned before, due lack of maturity I don’t think LTS is an option, thus no patch releases. (of course, if something huge happens like log4j , we can always come back to ML and propose a new release “off-cycle”). And I’m still in favor of my proposed alternative, adjusted to 10-12weeks of space between releases, based on general feedback. - Alex On Wed, Jan 15, 2025 at 4:12 AM Dominik Hanak <domin.ha...@gmail.com> wrote: > Every three months sounds reasonable. > > Would it be possible to specify the proposal in greater detail? Like when > do we do `minor`, `major`, `bugfix` releases, how do we approach > critical/blocker CVE's that can't wait for 3 months? > What is our LTS? How long do we support a release and such policies? Or do > you think this is off-topic? ( let me know I ll move it to new thread ) > I am asking mainly because > in kiegroup we had some components that used to be sometime released in a > sense "out of the loop" - mostly > components from kie-tools like vscode-extensions, chrome-extensions, web > tools. These were often released > with a new minor bugfix version update after we did release, of course only > if that made sense, be it blocker or enhancement. > The idea was that a blocker, for example, in vscode extension does not > warrant a new release of the whole stack. > Do we plan to allow such things going forward? > > I supported the no answer, but a voice in my head suggests to me that in a > specific case we could want to only release tooling. > So what are your opinions on this? I need to clarify this before "plus > oneing". > > Dominik > > On Tue, 14 Jan 2025 at 14:55, Fabrizio Antonangeli < > fantonang...@apache.org> > wrote: > > > +1 for every three months. I would add that this can be a flexible > > target according to which functionalities we are developing. > > For instance if we are developing a major release which takes 2 > > additional months, we can decide to release a minor earlier or a major > > after 3+2 months. > > I also agree releasing every month can be too much. > > > > On Tue, 2025-01-14 at 13:23 +0100, Pere Fernandez (apache) wrote: > > > I'm also +1 for one every three months. I don't think we could > > > currently > > > keep a 1 month cadence now. > > > > > > On Tue, 14 Jan 2025 at 13:20, Tibor Zimányi <tzima...@apache.org> > > > wrote: > > > > > > > Hi, > > > > > > > > after the responses I agree 1 per month is too much for now. One > > > > per three > > > > months should be fine as suggested. > > > > > > > > Best regards, > > > > Tibor > > > > > > > > Dňa ut 14. 1. 2025, 12:38 Yeser Amer <ya...@apache.org> napísal(a): > > > > > > > > > I tend to agree with the last comments. > > > > > > > > > > 3 months is a good compromise considering the current project > > > > > status. > > > > > > > > > > Yeser > > > > > > > > > > On 2025/01/14 11:12:37 Enrique Gonzalez Martinez wrote: > > > > > > Agreed that one month that might be overkilling as keeping in > > > > > > mind > > > > > > Dev + Code Freeze + Test (RC1...RCn) + Release > > > > > > It is way too much. This will lead to project resources > > > > > > starvation as > > > > > > we will spend more releasing that doing stuff. > > > > > > Any feature in the backend can take easily 1 month (any > > > > > > interesting > > > > > > stuff) best case scenario, so at least 2 months release would > > > > > > be the > > > > > > minimum. > > > > > > > > > > > > Cheers :) > > > > > > > > > > > > El mar, 14 ene 2025 a las 12:04, Toni Rikkola > > > > > > (<trikk...@redhat.com>) > > > > > escribió: > > > > > > > > > > > > > > Every 3 months would likely be a good starting point. If > > > > > > > automation > > > > > ends up > > > > > > > being high enough, then once a month should not be an issue. > > > > > > > > > > > > > > With everything that is missing for graduation I suspect we > > > > > > > have to > > > > > freeze > > > > > > > the code base every now and then, not ideal, but the easiest > > > > > > > path to > > > > > get > > > > > > > things done. This will slow down the PR streams making once a > > > > > > > month > > > > > > > releases less effective. > > > > > > > > > > > > > > Toni > > > > > > > > > > > > > > On Tue, Jan 14, 2025 at 12:14 PM Jozef Marko > > > > > <jozef.ma...@ibm.com.invalid> > > > > > > > wrote: > > > > > > > > > > > > > > > Hi, my personal opinion or experience is that 1 month > > > > > > > > cadence will > > > > > not > > > > > > > > work. A people that are members of the Apache KIE community > > > > > > > > work > > > > > also on > > > > > > > > other tasks. On tasks not related to the community release. > > > > > > > > I agree > > > > > good > > > > > > > > software should have often releases. One month is too brave > > > > > > > > goal in > > > > > my > > > > > > > > opinion. The window to do a release should be longer from > > > > > > > > my point > > > > > of view. > > > > > > > > > > > > > > > > > > > > > > > > Jozef Marko > > > > > > > > > > > > > > > > Software Developer > > > > > > > > > > > > > > > > jozef.ma...@ibm.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Tibor Zimányi <tzima...@apache.org> > > > > > > > > Sent: Friday, January 10, 2025 3:35 PM > > > > > > > > To: dev@kie.apache.org <dev@kie.apache.org> > > > > > > > > Subject: [EXTERNAL] [PROPOSAL] Release cadence > > > > > > > > stabilization > > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > I personally think that after our first release, the most > > > > > > > > important > > > > > topic > > > > > > > > right now is to make sure we don't wait another year for > > > > > > > > another > > > > > release. > > > > > > > > Therefore I think it is important to define the release > > > > > > > > cadence > > > > that > > > > > we > > > > > > > > will follow and define a workflow, that we will follow in > > > > > > > > regular > > > > > time > > > > > > > > intervals, based on the agreed cadence. If you would agree, > > > > > > > > we > > > > > should first > > > > > > > > make sure we have regular releases again and then we could > > > > > > > > open > > > > more > > > > > broad > > > > > > > > and impactful discussions about repositories structure, > > > > > > > > etc. > > > > > Otherwise we > > > > > > > > risk being blocked for another year by these discussions. > > > > > > > > So here > > > > is > > > > > my > > > > > > > > proposal for the release cadence: > > > > > > > > > > > > > > > > - Release should be done each month. > > > > > > > > - There should be a vote about a person responsible for > > > > > > > > these > > > > monthly > > > > > > > > releases. We need to have a specific person that makes sure > > > > > > > > the > > > > > release > > > > > > > > workflow is progressing. The person doesn't need to do the > > > > > > > > actual > > > > > work, > > > > > > > > however should make sure the release process is being done > > > > > > > > in a > > > > > timely > > > > > > > > manner. > > > > > > > > - The person responsible for the release, makes sure the > > > > > > > > documented > > > > > > > > standard release process is followed. > > > > > > > > > > > > > > > > This is a very rough proposal. I am open for feedback or > > > > > > > > other > > > > > proposals. I > > > > > > > > just think we should stabilize releases before we dive into > > > > > > > > more > > > > > broad > > > > > > > > discussions that could take months. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Tibor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Saludos, Enrique González Martínez :) > > > > > > > > > > > > --------------------------------------------------------------- > > > > > > ------ > > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > > > > > ---- > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > >
