Re: ASF board report due in two days!
This report has been published. Thank you again for your contributions!
Bruce
On Wed, Apr 12, 2023 at 9:13 AM Bruce Snyder wrote:
> Thank you to everyone who has contributed! Most appreciated.
>
> Bruce
>
> On Wed, Apr 12, 2023 at 8:08 AM Jean-Baptiste Onofré
> wrote:
>
>> +1
>>
>> it looks good, thanks !
>>
>> Sorry I was busy and didn't have time to add content to the report.
>>
>> Regards
>> JB
>>
>> On Wed, Apr 12, 2023 at 12:34 PM Robbie Gemmell
>> wrote:
>> >
>> > I fleshed out the report with the stats + releases etc detail, tweaked
>> > the earlier additions from Justin and Matt, and reflowed things so it
>> > can be submitted directly via Whimsy.
>> >
>> >
>> https://github.com/apache/activemq-website/commit/8035b7148bba966f8d72aba682fc8a118cdecbbf
>> >
>> >
>> https://github.com/apache/activemq-website/blob/8035b7148bba966f8d72aba682fc8a118cdecbbf/src/team/reports/DRAFT-ActiveMQ-board-report.txt
>> >
>> > Robbie
>> >
>> > On Tue, 11 Apr 2023 at 20:36, Bruce Snyder
>> wrote:
>> > >
>> > > So far, there have been zero contributions to the board report and
>> it's due
>> > > tomorrow. Please contribute to this month's board report so I can
>> submit it
>> > > tomorrow.
>> > >
>> > > Bruce
>> > >
>> > > On Mon, Apr 10, 2023 at 11:36 AM Bruce Snyder > >
>> > > wrote:
>> > >
>> > > > It looks like we got notified late again regarding this month's
>> board
>> > > > report and it's due in two days!
>> > > >
>> > > > Please provide your contributions for this board report by adding
>> them to
>> > > > the following file already in the git repo:
>> > > >
>> > > >
>> > > >
>> https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt
>> > > >
>> > > >
>> > > > Bruce
>> > > >
>> > > > --
>> > > > perl -e 'print
>> > > >
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E> > > > http://bsnyder.org/
Re: ASF board report due in two days!
Thank you to everyone who has contributed! Most appreciated.
Bruce
On Wed, Apr 12, 2023 at 8:08 AM Jean-Baptiste Onofré
wrote:
> +1
>
> it looks good, thanks !
>
> Sorry I was busy and didn't have time to add content to the report.
>
> Regards
> JB
>
> On Wed, Apr 12, 2023 at 12:34 PM Robbie Gemmell
> wrote:
> >
> > I fleshed out the report with the stats + releases etc detail, tweaked
> > the earlier additions from Justin and Matt, and reflowed things so it
> > can be submitted directly via Whimsy.
> >
> >
> https://github.com/apache/activemq-website/commit/8035b7148bba966f8d72aba682fc8a118cdecbbf
> >
> >
> https://github.com/apache/activemq-website/blob/8035b7148bba966f8d72aba682fc8a118cdecbbf/src/team/reports/DRAFT-ActiveMQ-board-report.txt
> >
> > Robbie
> >
> > On Tue, 11 Apr 2023 at 20:36, Bruce Snyder
> wrote:
> > >
> > > So far, there have been zero contributions to the board report and
> it's due
> > > tomorrow. Please contribute to this month's board report so I can
> submit it
> > > tomorrow.
> > >
> > > Bruce
> > >
> > > On Mon, Apr 10, 2023 at 11:36 AM Bruce Snyder
> > > wrote:
> > >
> > > > It looks like we got notified late again regarding this month's board
> > > > report and it's due in two days!
> > > >
> > > > Please provide your contributions for this board report by adding
> them to
> > > > the following file already in the git repo:
> > > >
> > > >
> > > >
> https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt
> > > >
> > > >
> > > > Bruce
> > > >
> > > > --
> > > > perl -e 'print
> > > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E );'
> > > > http://bsnyder.org/
Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker
Yup. I propose to update the website with a table with different versions (as we do in Karaf). Regards JB On Wed, Apr 12, 2023 at 4:08 PM Christopher Shannon wrote: > > Yep, this seems like a good plan to me. If people want to upgrade to > Jakarta we will have to require Spring 6 (due to the configuration) which > requires JDK 17 and I think requiring JDK 17 is reasonable for that version > as JDK 21 is almost out. > > I also want to add that we should upgrade 5.18.x to Jetty 10.x and 5.19.x > can be Jetty 11/12 > > On Wed, Apr 12, 2023 at 9:58 AM Matt Pavlovich wrote: > > > Hi Robbie- > > > > Yep, I’m back to agreeing with planning to move forward with the two > > separate versions is the way to go. Chris Shannon has the jetty > > continuation thing resolved, so that was the only potential snag for back > > porting. > > > > Proposed plan for 5.19.x and to LTS-ify 5.18.x: > > > > 5.18.x LTS - JDK 11 + javax broker + Spring 5 + activemq-client-jakarta > > 5.19.x- JDK 17 + jakarta broker + Spring 6 > > > > Thanks, > > Matt Pavlovich > > > > > On Apr 5, 2023, at 12:34 PM, Robbie Gemmell > > wrote: > > > > > > I dont really understand what your table of combinations entries say, > > > and so why Option 1 would be to support "3 (or more)" LTS branches but > > > the other only 2, so its hard to reply specifically around that. > > > > > > Adding -javax modules on a new branch thats primary-jakarta just > > > doesnt really make sense to me if still supporting an older version > > > that is actually primary-javax. There may be something obvious I'm > > > missing, but it seems more likely the people who are not updating APIs > > > also wont typically want to change all their dependencies in order to > > > not-update their usage. Theyll just use the older still-supported > > > primary-javax version. Same way they often use absolutely ancient > > > versions now already. > > > > > > Adding -javax modules to a primary-jakarta version might make sense to > > > me as a final fallback when otherwise dropping support for all > > > primary-javax versions, when at that point either the user would have > > > to either update the API they use or have to rework their dependencies > > > in order to not update the API. Personally I think it would be simpler > > > just supporting an existing primary-javax version (or even make a > > > newer one), or to decide you have actually finally dropped javax > > > support. > > > > > > It would seem easy enough to continue targeting JDK 11 on a new branch > > > with the client at least, even if needing 17 for the broker, if > > > wanting to support Jakarta client-only users on JDK11 but taking the > > > rest up to 17 to bring in Spring 6 ? > > > > > > On Wed, 5 Apr 2023 at 15:57, Matt Pavlovich wrote: > > >> > > >> I agree w/ Chris. I don’t think there is harm in keeping a -jakarta > > client module in 5.18.x. It provides runway for users that lag on JDK > > adoption and are not using Spring 6. > > >> > > >> A couple of technical notes to keep in mind about JDK-Spring-Jakarta > > coupling *specific* to ActiveMQ 5: > > >> > > >> 1. Spring 6 support is needed to address user demand for Spring Boot > > Starter > > >> 2. The *-web modules _require_ JDK 17 due to spring-web dependency > > >> 3. *-web modules drag a JDK 17 runtime requirement for the Apache > > runtime distribution > > >> 4. All the other modules can be compiled JDK 11 for users with custom > > assemblies > > >> > > >> > > >> Based on my previous repackaging and the inflight Jakarta PR work, I > > think back porting patches b/w Jakarta and non-Jakarta isn’t going to > > require too much heavy lifting. > > >> > > >> a. javax vs jakarta change is isolated to import lines, which should > > rarely be in the patch diffs > > >> b. *-web modules don’t change frequently > > >> c. jetty-continuation (discontinued) to jakarta.servlet async is the > > biggest _coding_ change required, and we could do that in a javax-based LTS > > tree as well > > >> > > >> > > >> Based on the above: > > >> > > >> i. I don’t see a huge win with for Jakarta broker without Spring 6 > > (since we require spring-web) we’d have jakarta for some modules and javax > > for Servlet > > >> Ii. Providing *-javax modules would be a way to simplify managing a > > Spring 6 + JDK 17 + javax build without a separate branch and set of > > releases > > >> > > >> A table of potential combinations: > > >> > > >> 5.18.x - Spring 5 + JDK 11 + javax (client and broker) > > >> 5.18.x (-jakarta client) - Spring 5 + JDK 11 + jakarta (client-only) > > >> 5.19.x - Spring 6 + JDK 17 + jakarta (client and broker) > > >> 5.19.x (-javax modules) - Spring 6 + JDK 17 + javax (client and broker) > > >> > > >> > > >> Based on all the above, I think the discussion could be reduced to a > > couple practical options: > > >> > > >> Option 1: Gap versions and support 3 (or more) LTS branches and do not > > do -javax modules in 5.19.x > > >> > > >> Option 2: Add -javax modules to 5
Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker
Yep, this seems like a good plan to me. If people want to upgrade to Jakarta we will have to require Spring 6 (due to the configuration) which requires JDK 17 and I think requiring JDK 17 is reasonable for that version as JDK 21 is almost out. I also want to add that we should upgrade 5.18.x to Jetty 10.x and 5.19.x can be Jetty 11/12 On Wed, Apr 12, 2023 at 9:58 AM Matt Pavlovich wrote: > Hi Robbie- > > Yep, I’m back to agreeing with planning to move forward with the two > separate versions is the way to go. Chris Shannon has the jetty > continuation thing resolved, so that was the only potential snag for back > porting. > > Proposed plan for 5.19.x and to LTS-ify 5.18.x: > > 5.18.x LTS - JDK 11 + javax broker + Spring 5 + activemq-client-jakarta > 5.19.x- JDK 17 + jakarta broker + Spring 6 > > Thanks, > Matt Pavlovich > > > On Apr 5, 2023, at 12:34 PM, Robbie Gemmell > wrote: > > > > I dont really understand what your table of combinations entries say, > > and so why Option 1 would be to support "3 (or more)" LTS branches but > > the other only 2, so its hard to reply specifically around that. > > > > Adding -javax modules on a new branch thats primary-jakarta just > > doesnt really make sense to me if still supporting an older version > > that is actually primary-javax. There may be something obvious I'm > > missing, but it seems more likely the people who are not updating APIs > > also wont typically want to change all their dependencies in order to > > not-update their usage. Theyll just use the older still-supported > > primary-javax version. Same way they often use absolutely ancient > > versions now already. > > > > Adding -javax modules to a primary-jakarta version might make sense to > > me as a final fallback when otherwise dropping support for all > > primary-javax versions, when at that point either the user would have > > to either update the API they use or have to rework their dependencies > > in order to not update the API. Personally I think it would be simpler > > just supporting an existing primary-javax version (or even make a > > newer one), or to decide you have actually finally dropped javax > > support. > > > > It would seem easy enough to continue targeting JDK 11 on a new branch > > with the client at least, even if needing 17 for the broker, if > > wanting to support Jakarta client-only users on JDK11 but taking the > > rest up to 17 to bring in Spring 6 ? > > > > On Wed, 5 Apr 2023 at 15:57, Matt Pavlovich wrote: > >> > >> I agree w/ Chris. I don’t think there is harm in keeping a -jakarta > client module in 5.18.x. It provides runway for users that lag on JDK > adoption and are not using Spring 6. > >> > >> A couple of technical notes to keep in mind about JDK-Spring-Jakarta > coupling *specific* to ActiveMQ 5: > >> > >> 1. Spring 6 support is needed to address user demand for Spring Boot > Starter > >> 2. The *-web modules _require_ JDK 17 due to spring-web dependency > >> 3. *-web modules drag a JDK 17 runtime requirement for the Apache > runtime distribution > >> 4. All the other modules can be compiled JDK 11 for users with custom > assemblies > >> > >> > >> Based on my previous repackaging and the inflight Jakarta PR work, I > think back porting patches b/w Jakarta and non-Jakarta isn’t going to > require too much heavy lifting. > >> > >> a. javax vs jakarta change is isolated to import lines, which should > rarely be in the patch diffs > >> b. *-web modules don’t change frequently > >> c. jetty-continuation (discontinued) to jakarta.servlet async is the > biggest _coding_ change required, and we could do that in a javax-based LTS > tree as well > >> > >> > >> Based on the above: > >> > >> i. I don’t see a huge win with for Jakarta broker without Spring 6 > (since we require spring-web) we’d have jakarta for some modules and javax > for Servlet > >> Ii. Providing *-javax modules would be a way to simplify managing a > Spring 6 + JDK 17 + javax build without a separate branch and set of > releases > >> > >> A table of potential combinations: > >> > >> 5.18.x - Spring 5 + JDK 11 + javax (client and broker) > >> 5.18.x (-jakarta client) - Spring 5 + JDK 11 + jakarta (client-only) > >> 5.19.x - Spring 6 + JDK 17 + jakarta (client and broker) > >> 5.19.x (-javax modules) - Spring 6 + JDK 17 + javax (client and broker) > >> > >> > >> Based on all the above, I think the discussion could be reduced to a > couple practical options: > >> > >> Option 1: Gap versions and support 3 (or more) LTS branches and do not > do -javax modules in 5.19.x > >> > >> Option 2: Add -javax modules to 5.19.x and support 2 LTS branches > >> > >> Thanks, > >> Matt Pavlovich > >> > >>> On Apr 5, 2023, at 9:20 AM, Christopher Shannon < > christopher.l.shan...@gmail.com> wrote: > >>> > >>> All fair points Robbie. I'd still like to leave the jakarta client in > >>> 5.18.x just as it gives some compatibility for clients only even if > it's > >>> going to go away in 5.19.x. > >>> > >>> So
Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker
That's exactly my proposal :) +1 Regards JB On Wed, Apr 12, 2023 at 3:57 PM Matt Pavlovich wrote: > > Hi Robbie- > > Yep, I’m back to agreeing with planning to move forward with the two separate > versions is the way to go. Chris Shannon has the jetty continuation thing > resolved, so that was the only potential snag for back porting. > > Proposed plan for 5.19.x and to LTS-ify 5.18.x: > > 5.18.x LTS - JDK 11 + javax broker + Spring 5 + activemq-client-jakarta > 5.19.x- JDK 17 + jakarta broker + Spring 6 > > Thanks, > Matt Pavlovich > > > On Apr 5, 2023, at 12:34 PM, Robbie Gemmell > > wrote: > > > > I dont really understand what your table of combinations entries say, > > and so why Option 1 would be to support "3 (or more)" LTS branches but > > the other only 2, so its hard to reply specifically around that. > > > > Adding -javax modules on a new branch thats primary-jakarta just > > doesnt really make sense to me if still supporting an older version > > that is actually primary-javax. There may be something obvious I'm > > missing, but it seems more likely the people who are not updating APIs > > also wont typically want to change all their dependencies in order to > > not-update their usage. Theyll just use the older still-supported > > primary-javax version. Same way they often use absolutely ancient > > versions now already. > > > > Adding -javax modules to a primary-jakarta version might make sense to > > me as a final fallback when otherwise dropping support for all > > primary-javax versions, when at that point either the user would have > > to either update the API they use or have to rework their dependencies > > in order to not update the API. Personally I think it would be simpler > > just supporting an existing primary-javax version (or even make a > > newer one), or to decide you have actually finally dropped javax > > support. > > > > It would seem easy enough to continue targeting JDK 11 on a new branch > > with the client at least, even if needing 17 for the broker, if > > wanting to support Jakarta client-only users on JDK11 but taking the > > rest up to 17 to bring in Spring 6 ? > > > > On Wed, 5 Apr 2023 at 15:57, Matt Pavlovich wrote: > >> > >> I agree w/ Chris. I don’t think there is harm in keeping a -jakarta client > >> module in 5.18.x. It provides runway for users that lag on JDK adoption > >> and are not using Spring 6. > >> > >> A couple of technical notes to keep in mind about JDK-Spring-Jakarta > >> coupling *specific* to ActiveMQ 5: > >> > >> 1. Spring 6 support is needed to address user demand for Spring Boot > >> Starter > >> 2. The *-web modules _require_ JDK 17 due to spring-web dependency > >> 3. *-web modules drag a JDK 17 runtime requirement for the Apache runtime > >> distribution > >> 4. All the other modules can be compiled JDK 11 for users with custom > >> assemblies > >> > >> > >> Based on my previous repackaging and the inflight Jakarta PR work, I think > >> back porting patches b/w Jakarta and non-Jakarta isn’t going to require > >> too much heavy lifting. > >> > >> a. javax vs jakarta change is isolated to import lines, which should > >> rarely be in the patch diffs > >> b. *-web modules don’t change frequently > >> c. jetty-continuation (discontinued) to jakarta.servlet async is the > >> biggest _coding_ change required, and we could do that in a javax-based > >> LTS tree as well > >> > >> > >> Based on the above: > >> > >> i. I don’t see a huge win with for Jakarta broker without Spring 6 (since > >> we require spring-web) we’d have jakarta for some modules and javax for > >> Servlet > >> Ii. Providing *-javax modules would be a way to simplify managing a Spring > >> 6 + JDK 17 + javax build without a separate branch and set of releases > >> > >> A table of potential combinations: > >> > >> 5.18.x - Spring 5 + JDK 11 + javax (client and broker) > >> 5.18.x (-jakarta client) - Spring 5 + JDK 11 + jakarta (client-only) > >> 5.19.x - Spring 6 + JDK 17 + jakarta (client and broker) > >> 5.19.x (-javax modules) - Spring 6 + JDK 17 + javax (client and broker) > >> > >> > >> Based on all the above, I think the discussion could be reduced to a > >> couple practical options: > >> > >> Option 1: Gap versions and support 3 (or more) LTS branches and do not do > >> -javax modules in 5.19.x > >> > >> Option 2: Add -javax modules to 5.19.x and support 2 LTS branches > >> > >> Thanks, > >> Matt Pavlovich > >> > >>> On Apr 5, 2023, at 9:20 AM, Christopher Shannon > >>> wrote: > >>> > >>> All fair points Robbie. I'd still like to leave the jakarta client in > >>> 5.18.x just as it gives some compatibility for clients only even if it's > >>> going to go away in 5.19.x. > >>> > >>> So how about the following: > >>> > >>> 5.18.x - Still javax support with just a jakarta client. This can be a > >>> long > >>> term LTS, at least for bug fixes. We will probably want to backport some > >>> features too for a while. > >>> 5.19.x - Becomes Ja
Re: ASF board report due in two days!
+1
it looks good, thanks !
Sorry I was busy and didn't have time to add content to the report.
Regards
JB
On Wed, Apr 12, 2023 at 12:34 PM Robbie Gemmell
wrote:
>
> I fleshed out the report with the stats + releases etc detail, tweaked
> the earlier additions from Justin and Matt, and reflowed things so it
> can be submitted directly via Whimsy.
>
> https://github.com/apache/activemq-website/commit/8035b7148bba966f8d72aba682fc8a118cdecbbf
>
> https://github.com/apache/activemq-website/blob/8035b7148bba966f8d72aba682fc8a118cdecbbf/src/team/reports/DRAFT-ActiveMQ-board-report.txt
>
> Robbie
>
> On Tue, 11 Apr 2023 at 20:36, Bruce Snyder wrote:
> >
> > So far, there have been zero contributions to the board report and it's due
> > tomorrow. Please contribute to this month's board report so I can submit it
> > tomorrow.
> >
> > Bruce
> >
> > On Mon, Apr 10, 2023 at 11:36 AM Bruce Snyder
> > wrote:
> >
> > > It looks like we got notified late again regarding this month's board
> > > report and it's due in two days!
> > >
> > > Please provide your contributions for this board report by adding them to
> > > the following file already in the git repo:
> > >
> > >
> > > https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt
> > >
> > >
> > > Bruce
> > >
> > > --
> > > perl -e 'print
> > > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > > http://bsnyder.org/
Re: [PROPOSAL] Jakarta approach for ActiveMQ 5.x broker
Hi Robbie- Yep, I’m back to agreeing with planning to move forward with the two separate versions is the way to go. Chris Shannon has the jetty continuation thing resolved, so that was the only potential snag for back porting. Proposed plan for 5.19.x and to LTS-ify 5.18.x: 5.18.x LTS - JDK 11 + javax broker + Spring 5 + activemq-client-jakarta 5.19.x- JDK 17 + jakarta broker + Spring 6 Thanks, Matt Pavlovich > On Apr 5, 2023, at 12:34 PM, Robbie Gemmell wrote: > > I dont really understand what your table of combinations entries say, > and so why Option 1 would be to support "3 (or more)" LTS branches but > the other only 2, so its hard to reply specifically around that. > > Adding -javax modules on a new branch thats primary-jakarta just > doesnt really make sense to me if still supporting an older version > that is actually primary-javax. There may be something obvious I'm > missing, but it seems more likely the people who are not updating APIs > also wont typically want to change all their dependencies in order to > not-update their usage. Theyll just use the older still-supported > primary-javax version. Same way they often use absolutely ancient > versions now already. > > Adding -javax modules to a primary-jakarta version might make sense to > me as a final fallback when otherwise dropping support for all > primary-javax versions, when at that point either the user would have > to either update the API they use or have to rework their dependencies > in order to not update the API. Personally I think it would be simpler > just supporting an existing primary-javax version (or even make a > newer one), or to decide you have actually finally dropped javax > support. > > It would seem easy enough to continue targeting JDK 11 on a new branch > with the client at least, even if needing 17 for the broker, if > wanting to support Jakarta client-only users on JDK11 but taking the > rest up to 17 to bring in Spring 6 ? > > On Wed, 5 Apr 2023 at 15:57, Matt Pavlovich wrote: >> >> I agree w/ Chris. I don’t think there is harm in keeping a -jakarta client >> module in 5.18.x. It provides runway for users that lag on JDK adoption and >> are not using Spring 6. >> >> A couple of technical notes to keep in mind about JDK-Spring-Jakarta >> coupling *specific* to ActiveMQ 5: >> >> 1. Spring 6 support is needed to address user demand for Spring Boot Starter >> 2. The *-web modules _require_ JDK 17 due to spring-web dependency >> 3. *-web modules drag a JDK 17 runtime requirement for the Apache runtime >> distribution >> 4. All the other modules can be compiled JDK 11 for users with custom >> assemblies >> >> >> Based on my previous repackaging and the inflight Jakarta PR work, I think >> back porting patches b/w Jakarta and non-Jakarta isn’t going to require too >> much heavy lifting. >> >> a. javax vs jakarta change is isolated to import lines, which should rarely >> be in the patch diffs >> b. *-web modules don’t change frequently >> c. jetty-continuation (discontinued) to jakarta.servlet async is the >> biggest _coding_ change required, and we could do that in a javax-based LTS >> tree as well >> >> >> Based on the above: >> >> i. I don’t see a huge win with for Jakarta broker without Spring 6 (since we >> require spring-web) we’d have jakarta for some modules and javax for Servlet >> Ii. Providing *-javax modules would be a way to simplify managing a Spring 6 >> + JDK 17 + javax build without a separate branch and set of releases >> >> A table of potential combinations: >> >> 5.18.x - Spring 5 + JDK 11 + javax (client and broker) >> 5.18.x (-jakarta client) - Spring 5 + JDK 11 + jakarta (client-only) >> 5.19.x - Spring 6 + JDK 17 + jakarta (client and broker) >> 5.19.x (-javax modules) - Spring 6 + JDK 17 + javax (client and broker) >> >> >> Based on all the above, I think the discussion could be reduced to a couple >> practical options: >> >> Option 1: Gap versions and support 3 (or more) LTS branches and do not do >> -javax modules in 5.19.x >> >> Option 2: Add -javax modules to 5.19.x and support 2 LTS branches >> >> Thanks, >> Matt Pavlovich >> >>> On Apr 5, 2023, at 9:20 AM, Christopher Shannon >>> wrote: >>> >>> All fair points Robbie. I'd still like to leave the jakarta client in >>> 5.18.x just as it gives some compatibility for clients only even if it's >>> going to go away in 5.19.x. >>> >>> So how about the following: >>> >>> 5.18.x - Still javax support with just a jakarta client. This can be a long >>> term LTS, at least for bug fixes. We will probably want to backport some >>> features too for a while. >>> 5.19.x - Becomes Jakarta API only. Still support JDK 11 and by default >>> would still have Spring 5.3.x but will be of course compatible with Spring >>> 6 and Spring boot 3, etc. >>> 5.20.x - By this release JDK 21 LTS should be out so I say we bump to >>> require JDK 17 (we can bump other things like Jetty/Spring 6 at the same >>> time
Re: ASF board report due in two days!
Looks good! Thanks, Robbie.
> On Apr 12, 2023, at 5:34 AM, Robbie Gemmell wrote:
>
> I fleshed out the report with the stats + releases etc detail, tweaked
> the earlier additions from Justin and Matt, and reflowed things so it
> can be submitted directly via Whimsy.
>
> https://github.com/apache/activemq-website/commit/8035b7148bba966f8d72aba682fc8a118cdecbbf
>
> https://github.com/apache/activemq-website/blob/8035b7148bba966f8d72aba682fc8a118cdecbbf/src/team/reports/DRAFT-ActiveMQ-board-report.txt
>
> Robbie
>
> On Tue, 11 Apr 2023 at 20:36, Bruce Snyder wrote:
>>
>> So far, there have been zero contributions to the board report and it's due
>> tomorrow. Please contribute to this month's board report so I can submit it
>> tomorrow.
>>
>> Bruce
>>
>> On Mon, Apr 10, 2023 at 11:36 AM Bruce Snyder
>> wrote:
>>
>>> It looks like we got notified late again regarding this month's board
>>> report and it's due in two days!
>>>
>>> Please provide your contributions for this board report by adding them to
>>> the following file already in the git repo:
>>>
>>>
>>> https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt
>>>
>>>
>>> Bruce
>>>
>>> --
>>> perl -e 'print
>>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E>> http://bsnyder.org/
Re: ASF board report due in two days!
I fleshed out the report with the stats + releases etc detail, tweaked
the earlier additions from Justin and Matt, and reflowed things so it
can be submitted directly via Whimsy.
https://github.com/apache/activemq-website/commit/8035b7148bba966f8d72aba682fc8a118cdecbbf
https://github.com/apache/activemq-website/blob/8035b7148bba966f8d72aba682fc8a118cdecbbf/src/team/reports/DRAFT-ActiveMQ-board-report.txt
Robbie
On Tue, 11 Apr 2023 at 20:36, Bruce Snyder wrote:
>
> So far, there have been zero contributions to the board report and it's due
> tomorrow. Please contribute to this month's board report so I can submit it
> tomorrow.
>
> Bruce
>
> On Mon, Apr 10, 2023 at 11:36 AM Bruce Snyder
> wrote:
>
> > It looks like we got notified late again regarding this month's board
> > report and it's due in two days!
> >
> > Please provide your contributions for this board report by adding them to
> > the following file already in the git repo:
> >
> >
> > https://github.com/apache/activemq-website/blob/main/src/team/reports/DRAFT-ActiveMQ-board-report.txt
> >
> >
> > Bruce
> >
> > --
> > perl -e 'print
> > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E > http://bsnyder.org/
Re: [VOTE] Apache ActiveMQ 5.18.1 release
+1 (non-binding) Thanks JB! regards, François On 11/04/2023 11:26, Jean-Baptiste Onofré wrote: Hi, I submit Apache ActiveMQ 5.18.1 release to your vote. This release fixes activemq-client-jakarta where the META-INF/services file was missing in the artifact. You can take a look on the Release Notes for details: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12352969 Maven Staging Repository: https://repository.apache.org/content/repositories/orgapacheactivemq-1278/ Dist Staging Repository: https://dist.apache.org/repos/dist/dev/activemq/activemq/5.18.1/ Git tag: activemq-5.18.1 Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Don't approve the release (please provide specific comments) This vote will be open for at least 72 hours. Thanks ! Regards JB -- -- François
