Does deprecating and removing something require 2 CHANGES.txt entries? 2 JIRAs? Maybe "it depends"; I'd imagine modules and major features should but I propose we have less work/toil/process to remove lesser stuff.
An example is SimpleMap, implemented by NamedList -- SOLR-14680. That issue was actually it's idea/creation that was merged (never had a CHANGES.txt entry). I used the same to deprecate it with a CHANGES.txt entry (although in hindsight I shouldn't have). Anyway, the deprecated code should be deleted. There are other examples -- individual methods on interfaces, like MapWriter.append or others I have in mind for DocCollection etc. It occurred to me that public methods/interfaces are a kind of liability. We can create them almost trivially. But removing them... not so much[*]. [*] unless we give ourselves the freedom to do so; more loose policies/guidelines[**] [**] as committers, we can actually commit at will; guidelines be damned. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
