I believe that one of the reasons people get stuck on really old versions of POI is that inevitably there are breaking changes in nearly every release. So folks pick a version, and it remains the one they use. If we were to shift to a semantic versioning scheme where we only introduced breaking fixes for major releases, we would probably have a better upgrade record, and we could say something like "We only support the last two major releases. You are going to have to upgrade." As it is, we have had two releases in the last year that contained breaking fixes. It would take some discipline on our part to do that, and we could specify which API's were subject to the Semantic versioning rules. For example HSSF and XSSF, but not those API's that we deem are still subject to change (everything else). Once an API is ready to be called stable, it ould fall under the semantic versioning rules. I think this would help the user community, and even projects with dependencies to POI.
-----Original Message----- From: Nick Burch [mailto:apa...@gagravarr.org] Sent: Tuesday, January 17, 2017 3:35 PM To: POI Developers List <dev@poi.apache.org> Subject: Re: Using Apache Commons IO On Tue, 17 Jan 2017, Javen O'Neal wrote: > In the spirit of "the best code is no code", how would you feel about > replacing our endian classes and IOUtils with Apache Commons IO? > > The downside is that it adds a dependency. > https://poi.apache.org/overview.html#components How many classes do we need? Do those classes include all the methods we need, or are there gaps? (Having dealt with yet another StackOverflow question today from someone stuck on a really old POI version, and knowing that the ones who make it to StackOverflow are actually the better ones, I'd rather inline a few classes / do nothing instead of adding a dependency that people can get wrong....) Nick --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
