Right, because the issue is not people having migrated but people migrating when jakarta releases are available so think you are right, it covers something like 0 user ;)
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 mer. 25 mai 2022 à 09:56, Zowalla, Richard < richard.zowa...@hs-heilbronn.de> a écrit : > Hi, > > JL wrote "Meanwhile, I'd create an issue on the TCK + Spec" in another > mail and as I want to learn something about the involved workflows / > processes (sorry - never had to deal with it): > > - What would we need to do to challenge the TCK + Spec in this regard? > - Who can do this - I assume it is vendor-driven, so PMC? > - Is it something super time consuming? > - Is it opening an issue and writing some elaborated text explaining > the situation / unclarity? > > I guess, that the user community who already migrated to jakarta.* > isn't that big at the moment (my assumption), so perhaps there is > enought time to open a challenge and clarify the situation. If users > complain, we can go still do a "bug" fix release? > > Gruß > Richard > > > > Am Mittwoch, dem 25.05.2022 um 09:03 +0200 schrieb Romain Manni-Bucau: > > Hi > > > > The small notes on that are: > > > > - rare impl actually do (asf ones but also other vendors), it is > > always a compromise between users/customers/consumers and specs > > - there is always a blurry line on some defaults (trivial example is > > default impl or provider impl even when defined in spec) > > - another blurry line is for libs vs distros > > > > So overall we are still free to choose in most cases even if we > > should tend to what you described. > > > > Side note: I dont want to emphasize the disrespect of that rule but > > the fact *we* must choose at the end. > > > > > > Le mer. 25 mai 2022 à 03:20, David Blevins <david.blev...@gmail.com> > > a écrit : > > > > On May 24, 2022, at 6:14 PM, David Blevins < > > > david.blev...@gmail.com> wrote: > > > > > > > > You could have flags that enabled non-compliant behavior, but > > > they would have to be off by default and require user action to > > > turn them on. > > > > > > To be clear I could have used a better word than "flags." You can > > > have any means you like to enable non-compliant behavior such as > > > annotations, alternate jars, etc. Anything that must be done > > > explicitly by a user to put themselves knowingly in a non-compliant > > > state. > > > > > > > > > -David > > > >
