> On Oct 1, 2021, at 4:25 AM, Jean-Louis Monteiro <[email protected]> > wrote: > > I was about to add that into tomee-jakarta by having the same approach so > we don't have the cost of maintaining both TomEE 8 and TomEE source tree. > > But looks like to do that we end up by duplicating pretty much the entire > TomEE tree but the examples. > > Is it worth it? > Should we move master to Jakarta and leave a maintenance branch for TomEE 8?
I could probably get behind that goal. I was originally not in favor of switching master over to the jakarta namespace, but now that we have some experience I think we're more or less forced to do it. Some things that changed my mind: - Our first release proved releasing both 8 & 9 together can be impractical. The TomEE 8 binaries were a dud, only TomEE 9 was released. There was communication overhead and made for a potentially confusing release. The TomEE 9 binaries are still very limited. - Our first release proved releasing both 8 & 9 together can be impractical. The TomEE 8 binaries were released, we didn't release TomEE 9. It's the second time we've done that. We've only managed one TomEE 9 release in the last 10 months. - It's difficult to make progress on TomEE 9 without impacting TomEE 8 negatively. - We've taken the bytecode tooling as far as we can take it. I don't see a way to get the arquillian adapters and plain maven dependencies working without a very large amount of work with odd tradeoffs. Work that will all be thrown away once we do a source rename. I think we gave it our best shot, but likely we're at the end of the road unless we're happy to have another year of the same or we get more volunteers to do bytecode work and ensure both TomEE 8 and 9 are released together. -David
smime.p7s
Description: S/MIME cryptographic signature
