Hi, I also think that we should be able to break binary compatibility in rare cases where it is cumbersome to maintain full compatibility. Also replacing things that likely only very few people use outside of POI (e.g. I don't think any users actually use POILogger in their code, or?) should be possible, either by announcing the de-support by deprectating it or by describing easy steps to adjust user-code.
What would help in the long run would be a notion of "internal" classes which we don't expect people to use on the outside. Some other projects use this and can then break stuff in these "internal" packages as needed. Also an official guideline to our users for how long we keep deprecated code would help to free the code from cruft, e.g. by stating that after 2 releases in deprecated state we can remove things for good. Many other projects do it this way successfully. Regarding slf4j, we could also look at commons-logging, this way we would stay with Apache managed projects and their license here and avoid the hassle with a custom license that is not approved/verified. Dominik. On Sun, Jun 21, 2015 at 12:46 AM, Andreas Beeker <kiwiwi...@apache.org> wrote: > Hi, > > I've just changed something in POILogger for #58040 and additionally > refactored the various methods to a varags method. > This works when code gets compiled but fails if only the binary is replaced. > > What is our guideline regarding ...? > - binary compatibility > - deprecated objects, i.e. org.apache.poi.openxml4j.opc.Package > > Nicks posts [1] says: > "Backwards compatibility - if possible we maintain binary compatibility, if > not source, and only break things if really needed." > > So binary compatibility means our dependencies? > and "if not source" means, it's ok when user code doesn't need to be changed, > but needs to be recompiled? > > How about allowing to remove deprecated stuff after 2 years (i.e. ages) after > it has been marked deprecated? > > Regarding the POILogger - I sometimes wonder, why we need to keep > (historical) things which in > the meantime exist in common. How about replacing POILogger by SLF4J? > (it seems to be compatible with ASL [2]) > > Best wishes, > Andi > > [1] > http://apache-poi.1045710.n5.nabble.com/Advice-for-new-and-potential-committers-td5718862.html > [2] http://www.slf4j.org/license.html > > --------------------------------------------------------------------- > 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
