Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)

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 | Blog | Old Blog

Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)

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

Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)

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

Re: Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)

> On May 24, 2022, at 6:14 PM, David Blevins 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

Dealing with compliance disagreements (was Re: [VOTE] Geronimo activation_2.0_spec 1.0.0)

Just wanted to echo what Jean-Louis said and add some details. During the 20 years of these specs living in the JCP, the license requirements stated that you must agree to ship your implementation with all defaults set to the compliant state. You could have flags that enabled non-compliant