BC can be handled a couple ways here besides renaming: * Are there already abstract classes that implementations are meant to extend? If so, that limits the possibility of problems here without using default methods in Java 8. * If these are truly public interfaces for users to implement, then you can extend the interface with an extended version which adds new methods. Try not to name them Options31 if you can help it.
On 12 March 2017 at 05:16, henrib <hen...@apache.org> wrote: > > I've reworded the warning about the source compatibility break in the > release notes: > > > > If this source compatibility break is not 'permitted' despite its > improbability, what option should we take: > - move to another (jexl31) package ? > - add 'extended' interfaces (Options31, JexlExpression31, Template31) ? > - add a utility helper class (Jexl31Helper?) to put the 3 methods as > functions ( boolean isCancellable(JExlEngine.Options opt) ? > > > Comments welcome, > Thanks > > > > -- > View this message in context: http://apache-commons.680414. > n4.nabble.com/jexl-3-1-release-review-tp4691513p4696416.html > Sent from the Commons - Dev mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker <boa...@gmail.com>
