Hi, this is partly a follow up to [1] and [2] - and sorry in advance to bring this up again, but I feel we are too conservative.
Summary: When we introduce new methods/enums/classes/... we try to be compile compatible with older versions. After two releases the deprecated stuff can be removed. Logic can be annotated internal, making it easier to change. Does "release" mean a final or a beta release? If it's a beta, it would probably make more sense to remove the deprecated stuff in the final release and not spanning it over to the next final round. But then one could also drop the deprecated stuff immediately, because it's just a beta ... I'm not sure if the following conclusions based on the download stats [3] (only PMCs) are valid: There's not much interest in betas after the final is out (... I know captain obvious is greeting) 3.9 is still quite frequently requested - the later version are approx. equally downloaded. - are people are so slowly adapting, because the older version satisfy their needs? - if we have the 2-release-deprecate-rule, does this really matter, i.e. are people gradually upgrading the version or do they jump over several releases anyway and need to be prepared for api breaks? So lets assume we add a version comment to each deprecated element for a later removal. In this case we have to check the logic twice, when deprecating it and when removing it. I think this is tedious ... and the removing won't be done later ... having lots of deprecated stuff around (see HWPF), which nobody wants to touch. For X/HSLF I've decided to remove stuff immediately - having the scratchpad label as an excuse. I try to think about a measure, when something should be kept available for longer or can be removed immediately ... how about how often it used in the examples? i.e. if less than 2 matches are found -> removed it otherwise deprecate it Best wishes, Andi [1] http://apache-poi.1045710.n5.nabble.com/Logging-Binary-compatibility-tt5719152.html [2] https://bz.apache.org/bugzilla/show_bug.cgi?id=58636 [3] https://repository.apache.org/#central-stat --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
