Hey Andriy, Sounds like a workable plan. If 4.0.0 is still ongoing once TomEE 9 is released, I'd help there before moving onto any potential 4.1 work. I'd expect TomEE 10 work to go far into next year, so there's no immediate time pressure -- just trying to get a feel for how it might all come together.
Yeah, the dependencies are the hardest part. We still bytecode transform about 5 or 6 of them in TomEE 9. That would definitely be one of the ways I could help once I'm freed up after TomEE 9. -David > On Oct 9, 2022, at 11:10 AM, Andriy Redko <drr...@gmail.com> wrote: > > Thanks David. I think the most efficient way for CXF team is to focus on > 4.0.0. We have a few > blockers along the way which we are working on. To put it in perspective, > there are modules which > are excluded from the builds at the moment, no equivalent replacement of the > dependencies in Jakarta > space, but eventually those should be there. In any case, I think the way to > approach the contrubutions > to 4.1 could be to create the pull request against main (for now), once 4.0.0 > is branched off, it could > be merged. It may not the most convenient for you, but would help us to focus > on 4.0.0 only. What do you > think? > > Thank you. > > Best Regards, > Andriy Redko > >>> On Oct 8, 2022, at 8:21 PM, Andriy Redko <drr...@gmail.com> wrote: >>> >>> I was thinking about that as well, since Jakarta EE 10 is already out [1]. >>> If I am not mistaken, >>> we haven't discussed the future Jakarta plans yet, trying to address major >>> 4.0.0 migration issues. >>> Personally I was thinking that having 4.1.x release dedicated to Jakarta EE >>> 10 is probably way to >>> go (and consequently following this branching strategy for the future >>> Jakarta EE releases like >>> 4.2.x, 4.3.x, ...). I am curious what others think about that. > > DB> That sounds like a good plan to me. > > DB> I know on the TomEE side the community seems to be anxious to get 9 out > the door so work on 10 can start. Likely that means 9 will immediately get > branched and go into maintenance mode, which is a bit different to what we'd > normally do. Usually the next version doesn't really start for quite a few > months. > > DB> Do we think we might be willing to accept contributions on a potential > 4.1 pretty soon after 4.0 goes final or would there be some desire to let > 4.0.0 mature for a few months before starting a potential 4.1? > > > DB> -David >
smime.p7s
Description: S/MIME cryptographic signature
