Well, the main change is that it will go 2.x so we need to review what we change/drop at the same time (think we should drop extras for ex) so while I agree it can be fast to switch jakarta and get a 2.x it'd be sad to not take the time to make the project a "single" module (it is what it is as of today now we dropped most of extensions). And even if 3.x is always a good excuse to not do it this would be a pity for me.
So once again, if it is just to sed javax/jakarta I don't see any gain for the project nor users but only some risk. If we really go 2.x let's go but not half baked - which would hold a "final" release compared to current state. Hope it makes sense. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 10 janv. 2023 à 17:20, Jean-Louis Monteiro <jlmonte...@tomitribe.com> a écrit : > Yes agreed. The release or feature frequency makes it substainable > > Le mar. 10 janv. 2023, 14:37, Thomas Andraschko < > andraschko.tho...@gmail.com> > a écrit : > > > Yeah i understand your case with "only migrate when we implement new > > features" > > but i also have to say that currently its winter and i have more time > > > > so better now than never and its unlikely that we ship much releases this > > year, so i dont think we have any big or even any real overhead > > maybe only like merging 1 commit and do 1 release :D > > > > > > Romain Manni-Bucau <rmannibu...@gmail.com> schrieb am Di., 10. Jan. > 2023, > > 15:02: > > > > > I'll probably be on the same camps than for others, if you plan to impl > > new > > > jakarta features a clear +1 otherwise let's wait codebase need changes > > > cause it reduces costs until it happens (so more a -+0). > > > > > > Le mar. 10 janv. 2023 à 13:51, Jean-Louis Monteiro < > > > jlmonte...@tomitribe.com> > > > a écrit : > > > > > > > Big +1 > > > > After running into this for months, I don't see benefits in shading > > > really. > > > > Creating a maintenance branch for 2.x and moving main/master to 3.x > is > > > the > > > > way to go in my opinion. > > > > > > > > > > > > If you need, I can help. I upgraded already the BVal TCK in TomEE in > > this > > > > PR https://github.com/apache/tomee/pull/1002 > > > > > > > > So far I only see 4 failures but I need to update the API to EE 10 > and > > > run > > > > again. > > > > -- > > > > Jean-Louis Monteiro > > > > http://twitter.com/jlouismonteiro > > > > http://www.tomitribe.com > > > > > > > > > > > > On Tue, Jan 10, 2023 at 1:47 PM Thomas Andraschko < > > > > andraschko.tho...@gmail.com> wrote: > > > > > > > > > Hi, > > > > > > > > > > i would like to finally migrate BVal to the jakarta namespace. > > > > > WDYT? > > > > > I would create a 2.0.x branch and set master to 3.0.0-SNAPSHOT. > > > > > > > > > > I know that shading has benefits but as we dont have that many > > releases > > > > > each year, i dont think its a big problem for us to handle master > > and a > > > > > second branch if we really need a release. > > > > > Also check our JIRA - we dont have any recent bug reports. > > > > > > > > > > Best regards, > > > > > Thomas > > > > > > > > > > > > > > >
