From how we deal with Java releases at work... if it ain't broke, don't bother updating. When you update, expect things to break. Also, for those getting the releases via maven, it tends to encourage an == dependency, so you have to actively remember that you want to update the package.
I think my impression is that most projects will mark things as deprecated, but then (except in some cases) they often don't actually remove them, so when I see them, I assume that I should avoid it, but if I can't then it'll probably still be there for awhile. Guava explicitly calls out what version they will remove deprecated stuff, so I tend to take it more seriously. :) Dustin On 11/24/2015 07:44 PM, Andreas Beeker wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
