Vaadin7 requires Java 7, Vaadin 8 requires Java 8, so they are OK there. POI 3.17 already has breaking changes, so they have to put off incorporating my work until a larger release anyway, due to possible customer dependencies. Their next release will at least be using 3.16, so users like me can drop in a POI version up through 3.17 before more referenced deprecated APIs are removed.
As I diagram it more on my end, and work through the details, I suppose putting this in 3.17 might be fine on all fronts, as long as the changes follow the POI guidelines of deprecating but not removing methods and classes. It just means a fair amount of rework for me on my dependent projects and contributions, whenever it happens. There is a lot of code around OOXML charts in my project and Vaadin's. I suppose that means others will have the same issue - if we radically change things up, it will break a lot of code for a lot of people. Designing and planning such a move should be done carefully, APIs are about the hardest thing to do well, and require a lot of up-front design work, I've found. I'll start by finding some free time to look at the pull request, and see how much it breaks things for me. On Fri, Aug 11, 2017 at 3:03 PM Andreas Beeker <kiwiwi...@apache.org> wrote: > > I would prefer this wait until 3.18, for purely selfish reasons, as we've > > already released a beta for 3.17. > > The postponing is ok for me ... but afterwards you have the breaking > changes anyways > and the Vaadin guys (or you?) have to do the chart modifications twice ... > or Vaadin > might be stuck on 3.17 ... > > On the other hand ... I don't know to what degree POI is part of Vaadin, > but POI 4.0 would > lift the Java minimum [1] > > Andi > > [1] > https://vaadin.com/vaadin-documentation-portlet/framework/installing/installing-java.html > >
