Should we document that in this case we are not spec compliant for backwards compatibility reasons?
Am Do., 20. Juli 2023 um 12:53 Uhr schrieb Carsten Ziegeler < [email protected]>: > I think there is no one solution fits all here. As always it depends. > > In general we should try to be spec compliant - unless there is a good > reason not to. There could be different reasons. > > In this particular case, imho there is a good reason to not be > compliant. We have a huge user base and the non spec compliant behaviour > is in there for many many years. There is a chance that some of our > users rely on this behaviour. If we change it, we break our users. Which > actually happened in this case. > > In addition, in this case if users are trying out our non spec compliant > method they will immediately see that it is not compliant during > development/testing. > > Regards > Carsten > > On 20.07.2023 12:28, Konrad Windszus wrote: > > Hi, > > Carsten just reverted the fix from > https://issues.apache.org/jira/browse/SLING-11825 in > https://issues.apache.org/jira/browse/SLING-11974. > > The fix is correct according to the Servlet Spec, but it seems some > customer rely on Sling behaving not spec compliant here. > > The question is what weighs more: > > 1) Spec compliance to make it easier for most new/existing users as > otherwise behaviour differs from Javadoc and underlying Spec. > > 2) Backwards compatibility for those users who rely on this spec > incompatibility. > > > > > > In my opinion I would clearly go for 1) but I would like to hear other > opinions. > > > > Thanks, > > Konrad > > -- > Carsten Ziegeler > Adobe > [email protected] > -- Cheers, Jörg Hoh, https://cqdump.joerghoh.de Twitter: @joerghoh
