Hi everyone, After spending the last year plus in a feature-boxed release scheduling mode, I think it would be both good and feasible to get the WildFly project back into the roughly time-boxed delivery model that we managed pretty successfully starting with WildFly 12. This thread is to gather inputs from the WildFly developer community about doing that over the next year. After discussing here, my aim is to post our plans to the broader WildFly community via a wildfly.org news post and a thread on the wildfly google group. One question is what length of time boxes we would shoot for. Personally I thought the roughly quarterly cadence worked well. It seemed short enough that we didn't find ourselves regularly stressing about getting a particular feature into a particular release because it would otherwise have to wait too long. I could imagine trying to go for a shorter cycle, but I don't think that's really practical right now. Optimizing our delivery processes to make that more practical would be a good goal for the next year though. If we go back to quarterly releases, the next question is what that schedule would look like. If we assume WildFly 28 goes out as planned[1], then a quarterly cadence would look like this: WildFly 29 Beta - Thur Jun 29 WildFly 29 Final – Thur Jul 13 WildFly 30 Beta – Thur Sep 28 WildFly 30 Final – Thur Oct 12 WildFly 31 Beta – Thur Dec 14 [2] WildFly 31 Final – Thur Jan 11 WildFly 32 Beta – Thur Mar 28 WildFly 32 Final -- Thur Apr 11 Those dates are the Thursdays when the release is announced on and download links are added to wildfly.org. We'd want PRs ready intended for the release to be ready to merge 6 days before that date, i.e. the preceding Friday. In the past we tried for a March/June/September/December cadence, but, besides that fact the April WildFly 28 will become a starting point, my sense is January/April/July/October will work better. A lot of developers go on holidays in late July and August, which tended to make September releases difficult. And then aiming for a mid-December Final release was often a problem, because any delay would push the release into the late December period when folks are away, driving the actual release into January. Even if that didn't happen, the possibility made December releases stressful. I don't think a strictly quarterly cadence is necessary; e.g. we could make the Apr-Jul release cycle a couple weeks shorter to get that release out of July and into June, if devs would find that better for their summer schedules. Note that my idea here isn't to come up with a set-in-stone schedule a year in advance. It's more to come up with general idea that we can promise to our community (e.g. 4 releases in a year) and a rough prediction when they will be. [1] https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... [2] Note that the WildFly 31 Beta date is significantly further ahead of the Final date than the typical 2 weeks. This is so the Beta is done and released before so many devs end work for the year. Best regards, Brian Stansberry Project Lead, WildFly

Thanks Brian for the information. It's great that WildFly goes back to a predictable time-boxed release schedule. The January/April/July/October looks better, it removes stress to hurry things in September (after summer holiday) and December (before time off). I was just wondering how new releases of Jakarta EE and MicroProfile could affect the schedule. Would we adapt the schedule for them? Or if we miss some implementation, we will release without them and add them in the next release? Thanks, jeff On Mon, Apr 3, 2023 at 7:17 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > Hi everyone, > > After spending the last year plus in a feature-boxed release scheduling > mode, I think it would be both good and feasible to get the WildFly project > back into the roughly time-boxed delivery model that we managed pretty > successfully starting with WildFly 12. This thread is to gather inputs from > the WildFly developer community about doing that over the next year. After > discussing here, my aim is to post our plans to the broader WildFly > community via a wildfly.org news post and a thread on the wildfly google > group. > > One question is what length of time boxes we would shoot for. > > Personally I thought the roughly quarterly cadence worked well. It seemed > short enough that we didn't find ourselves regularly stressing about > getting a particular feature into a particular release because it would > otherwise have to wait too long. I could imagine trying to go for a shorter > cycle, but I don't think that's really practical right now. Optimizing our > delivery processes to make that more practical would be a good goal for the > next year though. > > If we go back to quarterly releases, the next question is what that > schedule would look like. If we assume WildFly 28 goes out as planned[1], > then a quarterly cadence would look like this: > > WildFly 29 Beta - Thur Jun 29 > WildFly 29 Final – Thur Jul 13 > > WildFly 30 Beta – Thur Sep 28 > WildFly 30 Final – Thur Oct 12 > > WildFly 31 Beta – Thur Dec 14 [2] > WildFly 31 Final – Thur Jan 11 > > WildFly 32 Beta – Thur Mar 28 > WildFly 32 Final -- Thur Apr 11 > > Those dates are the Thursdays when the release is announced on and > download links are added to wildfly.org. We'd want PRs ready intended > for the release to be ready to merge 6 days before that date, i.e. the > preceding Friday. > > In the past we tried for a March/June/September/December cadence, but, > besides that fact the April WildFly 28 will become a starting point, my > sense is January/April/July/October will work better. A lot of developers > go on holidays in late July and August, which tended to make September > releases difficult. And then aiming for a mid-December Final release was > often a problem, because any delay would push the release into the late > December period when folks are away, driving the actual release into > January. Even if that didn't happen, the possibility made December releases > stressful. > > I don't think a strictly quarterly cadence is necessary; e.g. we could > make the Apr-Jul release cycle a couple weeks shorter to get that release > out of July and into June, if devs would find that better for their summer > schedules. > > Note that my idea here isn't to come up with a set-in-stone schedule a > year in advance. It's more to come up with general idea that we can promise > to our community (e.g. 4 releases in a year) and a rough prediction when > they will be. > > [1] > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... > > [2] Note that the WildFly 31 Beta date is significantly further ahead of > the Final date than the typical 2 weeks. This is so the Beta is done and > released before so many devs end work for the year. > > Best regards, > > Brian Stansberry > Project Lead, WildFly > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s -- Jeff Mesnil Principal Software Engineer Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Thanks, Scott. Personally, I think that's for the best. I think we *mostly* should not try to adapt a WildFly time-boxed release schedule to align with expected Jakarta EE or MicroProfile releases. And we should avoid feature boxing releases for them as well. I don't think Jakarta EE is at all predictable enough to try and schedule align. MicroProfile has historically been more predictable, but it's hard to align. To align well we'd need to go for 3 releases a year, for example late March / late July / late Nov. And then if the MP release was delayed, or our impl was delayed, it doesn't get in the WF release and the delay before it gets into the next WF is even longer. I said "mostly" above because I think our schedules should be "roughly" quarterly. I think it's fine to shift things around by two, maybe three, weeks if we think that will give us a chance to have a more meaningful release. So, for example, if we feel that MP is going to consistently do releases in June and we expect to be able to pick up that release quickly, maybe we'd schedule the July release for late July instead of mid July. The next release then has a shorter dev cycle. That's something we can foresee early in a release cycle and if we want such a shift we can adjust the release schedule that we announce for that release accordingly. If a major spec release comes out and for marketing purposes we want to certify as compatible on its release date we can always produce an alpha or beta, or even a minor. That's what we did with EE 10. EE platform updates are good examples of dev work that may not fit in a single time box. (Historically MP has been less of a problem.) I hope this year we can improve our feature delivery processes a lot and move toward a system where we can efficiently promote features to higher 'maturity' levels.[1] How exactly that would apply to EE spec updates is unclear to me, but the EE update use case is a good one to think about as we work on this stuff this year. In the end though, time-boxing means sometimes dev work needs to be maintained on a topic branch for a longer period. We've done that before. [1] See Paul Ferraro's https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to... and https://issues.redhat.com/browse/WFCORE-6221 for one aspect of this, focused on the management API. Best regards, Brian On Thu, Apr 6, 2023 at 9:56 AM Scott Stark <sstark(a)redhat.com&gt; wrote: > The earliest EE11 could be out is Q1 2024. I don't see that happening. I > would expect something in Q4 2024 at the earliest. > > > On Apr 6, 2023 at 8:50:54 AM, Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: > >> Thanks Brian for the information. >> >> It's great that WildFly goes back to a predictable time-boxed release >> schedule. >> >> The January/April/July/October looks better, it removes stress to hurry >> things in September (after summer holiday) and December (before time off). >> >> I was just wondering how new releases of Jakarta EE and MicroProfile >> could affect the schedule. >> Would we adapt the schedule for them? Or if we miss some >> implementation, we will release without them and add them in the next >> release? >> >> Thanks, >> jeff >> >> >> >> >> On Mon, Apr 3, 2023 at 7:17 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> Hi everyone, >>> >>> After spending the last year plus in a feature-boxed release scheduling >>> mode, I think it would be both good and feasible to get the WildFly project >>> back into the roughly time-boxed delivery model that we managed pretty >>> successfully starting with WildFly 12. This thread is to gather inputs from >>> the WildFly developer community about doing that over the next year. After >>> discussing here, my aim is to post our plans to the broader WildFly >>> community via a wildfly.org news post and a thread on the wildfly >>> google group. >>> >>> One question is what length of time boxes we would shoot for. >>> >>> Personally I thought the roughly quarterly cadence worked well. It >>> seemed short enough that we didn't find ourselves regularly stressing about >>> getting a particular feature into a particular release because it would >>> otherwise have to wait too long. I could imagine trying to go for a shorter >>> cycle, but I don't think that's really practical right now. Optimizing our >>> delivery processes to make that more practical would be a good goal for the >>> next year though. >>> >>> If we go back to quarterly releases, the next question is what that >>> schedule would look like. If we assume WildFly 28 goes out as planned[1], >>> then a quarterly cadence would look like this: >>> >>> WildFly 29 Beta - Thur Jun 29 >>> WildFly 29 Final – Thur Jul 13 >>> >>> WildFly 30 Beta – Thur Sep 28 >>> WildFly 30 Final – Thur Oct 12 >>> >>> WildFly 31 Beta – Thur Dec 14 [2] >>> WildFly 31 Final – Thur Jan 11 >>> >>> WildFly 32 Beta – Thur Mar 28 >>> WildFly 32 Final -- Thur Apr 11 >>> >>> Those dates are the Thursdays when the release is announced on and >>> download links are added to wildfly.org. We'd want PRs ready intended >>> for the release to be ready to merge 6 days before that date, i.e. the >>> preceding Friday. >>> >>> In the past we tried for a March/June/September/December cadence, but, >>> besides that fact the April WildFly 28 will become a starting point, my >>> sense is January/April/July/October will work better. A lot of developers >>> go on holidays in late July and August, which tended to make September >>> releases difficult. And then aiming for a mid-December Final release was >>> often a problem, because any delay would push the release into the late >>> December period when folks are away, driving the actual release into >>> January. Even if that didn't happen, the possibility made December releases >>> stressful. >>> >>> I don't think a strictly quarterly cadence is necessary; e.g. we could >>> make the Apr-Jul release cycle a couple weeks shorter to get that release >>> out of July and into June, if devs would find that better for their summer >>> schedules. >>> >>> Note that my idea here isn't to come up with a set-in-stone schedule a >>> year in advance. It's more to come up with general idea that we can promise >>> to our community (e.g. 4 releases in a year) and a rough prediction when >>> they will be. >>> >>> [1] >>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>> >>> [2] Note that the WildFly 31 Beta date is significantly further ahead >>> of the Final date than the typical 2 weeks. This is so the Beta is done and >>> released before so many devs end work for the year. >>> >>> Best regards, >>> >>> Brian Stansberry >>> Project Lead, WildFly >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >> >> >> >> -- >> Jeff Mesnil >> Principal Software Engineer >> Red Hat >> http://jmesnil.net/ >> _______________________________________________ >> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >> > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His

So in yesterday's EE platform group call there has been pivot back to pushing for a Q1 EE11 release even if it contains very little. I complained about this and said it made no sense for us to spend time producing such a release. Two of the main proponents were not on the call, so there will have to be a more confrontational call next week. Bottom line is that is it not clear what resources will be marshaled to produce such a release, but Ed Burns from MSFT has signed up to co-lead EE11 with Arjan Tijms of OmniFish. On Wed, Apr 26, 2023 at 2:08 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > If there's no further input on this, I want to publish a blog post about > this on wildfly.org this week and mention the post on the wildfly google > group, twitter and fosstodon. > > I'll note that these are all estimates that can change, and specifically > that the WF 29 date may shift a couple weeks as we keep an eye on what > happens with any MicroProfile release in June. (Thanks for asking about > that, Jeff.) > > Cheers, > Brian > > On Thu, Apr 6, 2023 at 12:20 PM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> Thanks, Scott. Personally, I think that's for the best. >> >> I think we *mostly* should not try to adapt a WildFly time-boxed release >> schedule to align with expected Jakarta EE or MicroProfile releases. And we >> should avoid feature boxing releases for them as well. I don't think >> Jakarta EE is at all predictable enough to try and schedule align. >> MicroProfile has historically been more predictable, but it's hard to >> align. To align well we'd need to go for 3 releases a year, for example >> late March / late July / late Nov. And then if the MP release was delayed, >> or our impl was delayed, it doesn't get in the WF release and the delay >> before it gets into the next WF is even longer. >> >> I said "mostly" above because I think our schedules should be "roughly" >> quarterly. I think it's fine to shift things around by two, maybe three, >> weeks if we think that will give us a chance to have a more meaningful >> release. So, for example, if we feel that MP is going to consistently do >> releases in June and we expect to be able to pick up that release quickly, >> maybe we'd schedule the July release for late July instead of mid July. The >> next release then has a shorter dev cycle. That's something we can foresee >> early in a release cycle and if we want such a shift we can adjust the >> release schedule that we announce for that release accordingly. >> >> If a major spec release comes out and for marketing purposes we want to >> certify as compatible on its release date we can always produce an alpha or >> beta, or even a minor. That's what we did with EE 10. >> >> EE platform updates are good examples of dev work that may not fit in a >> single time box. (Historically MP has been less of a problem.) I hope this >> year we can improve our feature delivery processes a lot and move toward a >> system where we can efficiently promote features to higher 'maturity' >> levels.[1] How exactly that would apply to EE spec updates is unclear to >> me, but the EE update use case is a good one to think about as we work on >> this stuff this year. In the end though, time-boxing means sometimes dev >> work needs to be maintained on a topic branch for a longer period. We've >> done that before. >> >> [1] See Paul Ferraro's >> https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to... >> and https://issues.redhat.com/browse/WFCORE-6221 for one aspect of >> this, focused on the management API. >> >> Best regards, >> Brian >> >> On Thu, Apr 6, 2023 at 9:56 AM Scott Stark <sstark(a)redhat.com&gt; wrote: >> >>> The earliest EE11 could be out is Q1 2024. I don't see that happening. >>> I would expect something in Q4 2024 at the earliest. >>> >>> >>> On Apr 6, 2023 at 8:50:54 AM, Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: >>> >>>> Thanks Brian for the information. >>>> >>>> It's great that WildFly goes back to a predictable time-boxed release >>>> schedule. >>>> >>>> The January/April/July/October looks better, it removes stress >>>> to hurry things in September (after summer holiday) and December (before >>>> time off). >>>> >>>> I was just wondering how new releases of Jakarta EE and MicroProfile >>>> could affect the schedule. >>>> Would we adapt the schedule for them? Or if we miss some >>>> implementation, we will release without them and add them in the next >>>> release? >>>> >>>> Thanks, >>>> jeff >>>> >>>> >>>> >>>> >>>> On Mon, Apr 3, 2023 at 7:17 PM Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> After spending the last year plus in a feature-boxed release >>>>> scheduling mode, I think it would be both good and feasible to get the >>>>> WildFly project back into the roughly time-boxed delivery model that we >>>>> managed pretty successfully starting with WildFly 12. This thread is to >>>>> gather inputs from the WildFly developer community about doing that over >>>>> the next year. After discussing here, my aim is to post our plans to the >>>>> broader WildFly community via a wildfly.org news post and a thread >>>>> on the wildfly google group. >>>>> >>>>> One question is what length of time boxes we would shoot for. >>>>> >>>>> Personally I thought the roughly quarterly cadence worked well. It >>>>> seemed short enough that we didn't find ourselves regularly stressing about >>>>> getting a particular feature into a particular release because it would >>>>> otherwise have to wait too long. I could imagine trying to go for a shorter >>>>> cycle, but I don't think that's really practical right now. Optimizing our >>>>> delivery processes to make that more practical would be a good goal for the >>>>> next year though. >>>>> >>>>> If we go back to quarterly releases, the next question is what that >>>>> schedule would look like. If we assume WildFly 28 goes out as planned[1], >>>>> then a quarterly cadence would look like this: >>>>> >>>>> WildFly 29 Beta - Thur Jun 29 >>>>> WildFly 29 Final – Thur Jul 13 >>>>> >>>>> WildFly 30 Beta – Thur Sep 28 >>>>> WildFly 30 Final – Thur Oct 12 >>>>> >>>>> WildFly 31 Beta – Thur Dec 14 [2] >>>>> WildFly 31 Final – Thur Jan 11 >>>>> >>>>> WildFly 32 Beta – Thur Mar 28 >>>>> WildFly 32 Final -- Thur Apr 11 >>>>> >>>>> Those dates are the Thursdays when the release is announced on and >>>>> download links are added to wildfly.org. We'd want PRs ready >>>>> intended for the release to be ready to merge 6 days before that date, i.e. >>>>> the preceding Friday. >>>>> >>>>> In the past we tried for a March/June/September/December cadence, >>>>> but, besides that fact the April WildFly 28 will become a starting point, >>>>> my sense is January/April/July/October will work better. A lot of >>>>> developers go on holidays in late July and August, which tended to make >>>>> September releases difficult. And then aiming for a mid-December Final >>>>> release was often a problem, because any delay would push the release into >>>>> the late December period when folks are away, driving the actual release >>>>> into January. Even if that didn't happen, the possibility made December >>>>> releases stressful. >>>>> >>>>> I don't think a strictly quarterly cadence is necessary; e.g. we >>>>> could make the Apr-Jul release cycle a couple weeks shorter to get that >>>>> release out of July and into June, if devs would find that better for their >>>>> summer schedules. >>>>> >>>>> Note that my idea here isn't to come up with a set-in-stone schedule >>>>> a year in advance. It's more to come up with general idea that we can >>>>> promise to our community (e.g. 4 releases in a year) and a rough prediction >>>>> when they will be. >>>>> >>>>> [1] >>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>>> >>>>> [2] Note that the WildFly 31 Beta date is significantly further ahead >>>>> of the Final date than the typical 2 weeks. This is so the Beta is done and >>>>> released before so many devs end work for the year. >>>>> >>>>> Best regards, >>>>> >>>>> Brian Stansberry >>>>> Project Lead, WildFly >>>>> _______________________________________________ >>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>>> >>>> >>>> >>>> -- >>>> Jeff Mesnil >>>> Principal Software Engineer >>>> Red Hat >>>> http://jmesnil.net/ >>>> _______________________________________________ >>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>>> >>> >> >> -- >> Brian Stansberry >> Principal Architect, Red Hat JBoss EAP >> He/Him/His >> > > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > He/Him/His >

Scott Marlow and I just got off a call with Ed and Arjan about the TCK work needed and the timeframe is again back to Q4. The codename for this release should be whiplash. We will see how well that stands up. On Fri, Apr 28, 2023 at 7:33 AM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > Thanks for the info, Scott. > > If it turns out there really is an EE 11 in Q1 and if we wanted to pick > it up, it seems likely enough we could handle it. If it's small, maybe it > would make the April 2024 release, perhaps just in WildFly Preview if we > think whatever we've done needs more bake before appearing standard > WildFly. I think we should always give ourselves a couple weeks leeway on > any release schedule, so that would mean we'd have until the end of April. > > Or we just wait for the July 2024 release. > > It seems like the main pain point with these platform spec releases with > a time-boxed WildFly is if the spec lands too close to a time box end. That > puts us in a spot where we either have to delay the release or we can't > certify as compatible on spec release day with an alpha/beta, because our > code base is too locked down at that time. It seems like a "deal with it if > it happens" kind of scenario. > > TBH, if EE really does start releasing on a much more frequent cadence I > suspect personally I'll feel less motivated to certify on release day. It's > a great thing to do of course but there are many great things to do. > > If others feel otherwise that's a reason to reconsider time boxing. > Between EE and MP there might be 4 big spec releases a year; if we wanted > to make certifying on release day a key priority that means predictable > time boxing would not be practical; at best it could be something we do > sometimes. > > On Wed, Apr 26, 2023 at 11:03 PM Scott Stark <sstark(a)redhat.com&gt; wrote: > >> So in yesterday's EE platform group call there has been pivot back to >> pushing for a Q1 EE11 release even if it contains very little. I complained >> about this and said it made no sense for us to spend time producing such a >> release. Two of the main proponents were not on the call, so there will >> have to be a more confrontational call next week. Bottom line is that is it >> not clear what resources will be marshaled to produce such a release, but >> Ed Burns from MSFT has signed up to co-lead EE11 with Arjan Tijms of >> OmniFish. >> >> On Wed, Apr 26, 2023 at 2:08 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> If there's no further input on this, I want to publish a blog post >>> about this on wildfly.org this week and mention the post on the >>> wildfly google group, twitter and fosstodon. >>> >>> I'll note that these are all estimates that can change, and >>> specifically that the WF 29 date may shift a couple weeks as we keep an eye >>> on what happens with any MicroProfile release in June. (Thanks for asking >>> about that, Jeff.) >>> >>> Cheers, >>> Brian >>> >>> On Thu, Apr 6, 2023 at 12:20 PM Brian Stansberry < >>> brian.stansberry(a)redhat.com&gt; wrote: >>> >>>> Thanks, Scott. Personally, I think that's for the best. >>>> >>>> I think we *mostly* should not try to adapt a WildFly time-boxed >>>> release schedule to align with expected Jakarta EE or MicroProfile >>>> releases. And we should avoid feature boxing releases for them as well. I >>>> don't think Jakarta EE is at all predictable enough to try and schedule >>>> align. MicroProfile has historically been more predictable, but it's hard >>>> to align. To align well we'd need to go for 3 releases a year, for example >>>> late March / late July / late Nov. And then if the MP release was delayed, >>>> or our impl was delayed, it doesn't get in the WF release and the delay >>>> before it gets into the next WF is even longer. >>>> >>>> I said "mostly" above because I think our schedules should be >>>> "roughly" quarterly. I think it's fine to shift things around by two, maybe >>>> three, weeks if we think that will give us a chance to have a more >>>> meaningful release. So, for example, if we feel that MP is going to >>>> consistently do releases in June and we expect to be able to pick up that >>>> release quickly, maybe we'd schedule the July release for late July instead >>>> of mid July. The next release then has a shorter dev cycle. That's >>>> something we can foresee early in a release cycle and if we want such a >>>> shift we can adjust the release schedule that we announce for that release >>>> accordingly. >>>> >>>> If a major spec release comes out and for marketing purposes we want >>>> to certify as compatible on its release date we can always produce an alpha >>>> or beta, or even a minor. That's what we did with EE 10. >>>> >>>> EE platform updates are good examples of dev work that may not fit in >>>> a single time box. (Historically MP has been less of a problem.) I hope >>>> this year we can improve our feature delivery processes a lot and move >>>> toward a system where we can efficiently promote features to higher >>>> 'maturity' levels.[1] How exactly that would apply to EE spec updates is >>>> unclear to me, but the EE update use case is a good one to think about as >>>> we work on this stuff this year. In the end though, time-boxing means >>>> sometimes dev work needs to be maintained on a topic branch for a longer >>>> period. We've done that before. >>>> >>>> [1] See Paul Ferraro's >>>> https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to... >>>> and https://issues.redhat.com/browse/WFCORE-6221 for one aspect of >>>> this, focused on the management API. >>>> >>>> Best regards, >>>> Brian >>>> >>>> On Thu, Apr 6, 2023 at 9:56 AM Scott Stark <sstark(a)redhat.com&gt; wrote: >>>> >>>>> The earliest EE11 could be out is Q1 2024. I don't see that >>>>> happening. I would expect something in Q4 2024 at the earliest. >>>>> >>>>> >>>>> On Apr 6, 2023 at 8:50:54 AM, Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: >>>>> >>>>>> Thanks Brian for the information. >>>>>> >>>>>> It's great that WildFly goes back to a predictable time-boxed >>>>>> release schedule. >>>>>> >>>>>> The January/April/July/October looks better, it removes stress >>>>>> to hurry things in September (after summer holiday) and December (before >>>>>> time off). >>>>>> >>>>>> I was just wondering how new releases of Jakarta EE and MicroProfile >>>>>> could affect the schedule. >>>>>> Would we adapt the schedule for them? Or if we miss some >>>>>> implementation, we will release without them and add them in the next >>>>>> release? >>>>>> >>>>>> Thanks, >>>>>> jeff >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Apr 3, 2023 at 7:17 PM Brian Stansberry < >>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> After spending the last year plus in a feature-boxed release >>>>>>> scheduling mode, I think it would be both good and feasible to get the >>>>>>> WildFly project back into the roughly time-boxed delivery model that we >>>>>>> managed pretty successfully starting with WildFly 12. This thread is to >>>>>>> gather inputs from the WildFly developer community about doing that over >>>>>>> the next year. After discussing here, my aim is to post our plans to the >>>>>>> broader WildFly community via a wildfly.org news post and a thread >>>>>>> on the wildfly google group. >>>>>>> >>>>>>> One question is what length of time boxes we would shoot for. >>>>>>> >>>>>>> Personally I thought the roughly quarterly cadence worked well. It >>>>>>> seemed short enough that we didn't find ourselves regularly stressing about >>>>>>> getting a particular feature into a particular release because it would >>>>>>> otherwise have to wait too long. I could imagine trying to go for a shorter >>>>>>> cycle, but I don't think that's really practical right now. Optimizing our >>>>>>> delivery processes to make that more practical would be a good goal for the >>>>>>> next year though. >>>>>>> >>>>>>> If we go back to quarterly releases, the next question is what that >>>>>>> schedule would look like. If we assume WildFly 28 goes out as planned[1], >>>>>>> then a quarterly cadence would look like this: >>>>>>> >>>>>>> WildFly 29 Beta - Thur Jun 29 >>>>>>> WildFly 29 Final – Thur Jul 13 >>>>>>> >>>>>>> WildFly 30 Beta – Thur Sep 28 >>>>>>> WildFly 30 Final – Thur Oct 12 >>>>>>> >>>>>>> WildFly 31 Beta – Thur Dec 14 [2] >>>>>>> WildFly 31 Final – Thur Jan 11 >>>>>>> >>>>>>> WildFly 32 Beta – Thur Mar 28 >>>>>>> WildFly 32 Final -- Thur Apr 11 >>>>>>> >>>>>>> Those dates are the Thursdays when the release is announced on and >>>>>>> download links are added to wildfly.org. We'd want PRs ready >>>>>>> intended for the release to be ready to merge 6 days before that date, i.e. >>>>>>> the preceding Friday. >>>>>>> >>>>>>> In the past we tried for a March/June/September/December cadence, >>>>>>> but, besides that fact the April WildFly 28 will become a starting point, >>>>>>> my sense is January/April/July/October will work better. A lot of >>>>>>> developers go on holidays in late July and August, which tended to make >>>>>>> September releases difficult. And then aiming for a mid-December Final >>>>>>> release was often a problem, because any delay would push the release into >>>>>>> the late December period when folks are away, driving the actual release >>>>>>> into January. Even if that didn't happen, the possibility made December >>>>>>> releases stressful. >>>>>>> >>>>>>> I don't think a strictly quarterly cadence is necessary; e.g. we >>>>>>> could make the Apr-Jul release cycle a couple weeks shorter to get that >>>>>>> release out of July and into June, if devs would find that better for their >>>>>>> summer schedules. >>>>>>> >>>>>>> Note that my idea here isn't to come up with a set-in-stone >>>>>>> schedule a year in advance. It's more to come up with general idea that we >>>>>>> can promise to our community (e.g. 4 releases in a year) and a rough >>>>>>> prediction when they will be. >>>>>>> >>>>>>> [1] >>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>>>>> >>>>>>> [2] Note that the WildFly 31 Beta date is significantly further >>>>>>> ahead of the Final date than the typical 2 weeks. This is so the Beta is >>>>>>> done and released before so many devs end work for the year. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Brian Stansberry >>>>>>> Project Lead, WildFly >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jeff Mesnil >>>>>> Principal Software Engineer >>>>>> Red Hat >>>>>> http://jmesnil.net/ >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>>>>> >>>>> >>>> >>>> -- >>>> Brian Stansberry >>>> Principal Architect, Red Hat JBoss EAP >>>> He/Him/His >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Principal Architect, Red Hat JBoss EAP >>> He/Him/His >>> >> > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > He/Him/His >