Hi All, and Henri B in particular: (By user request), I was about to cut a release candidate for 3.6.0 BUT:
There is a binary compatibility breakage in master vs. 3.5.0: - final public class org.apache.commons.jexl3.JexlFeatures REMOVED public static final int STRICT_STATEMENT commit c224a05a0a75b05dc19c965519d8a6424e55d4cf Author: Henrib <[email protected]> 2025-06-06 15:17:27 Committer: Henrib <[email protected]> 2025-06-06 15:17:27 @@ -127,4 +127,4 @@ public static final int REF_CAPTURE = 24; - /** Captured variables are reference. */ - public static final int STRICT_STATEMENT = 25; + /** Ambiguous or strict statement allowed. */ + public static final int AMBIGUOUS_STATEMENT = 25; /** Unfortunately, this is hidden by: <breakBuildOnBinaryIncompatibleModifications>false</breakBuildOnBinaryIncompatibleModifications> and undocumented in changes.xml. We should strive to avoid breaking binary compatibility within a major release, and if we do, it must be justified and documented. Please explain and/or revert. Curiously, JApiCmp complains about: - org.apache.commons.jexl3.introspection.JexlUberspect$ClassNameResolver REMOVED public abstract java.lang.String resolveClassName(java.lang.String) BUT, it looks like ClassNameResolver was added since the last release, but is documented as added in 3.3 (@since 3.3). This must be some odd bug in JApiCmp, or, am I missing something? ClassConstantResolver and ConstantResolverFactory were also added, but not documented with @since 3.6.0. I propose: - RESTORE the constant STRICT_STATEMENT. What does this mean for the other constants in the class, like ALL_FEATURES? - REMOVE the property override breakBuildOnBinaryIncompatibleModifications - Javadoc the new interfaces with @since Thank you, Gary --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
