This is a minor public service reminder of our changelog types. I find myself "policing" these lately, even after they have been merged with incorrect info, which is annoying. The following is printed when a changelog is generated:
# type: > # `added` for new features/improvements, opt-in by the user typically > documented in the ref guide > # `changed` for improvements; not opt-in > # `fixed` for improvements that are deemed to have fixed buggy behavior > # `deprecated` for marking things deprecated > # `removed` for code removed > # `dependency_update` for updates to dependencies > # `other` for anything else, like large/significant refactorings, build > changes, > # test infrastructure, or documentation. > # Most such changes are too small/minor to bother with a changelog entry. > > In particular I want to draw attention to the semantic difference between "added" vs "changed". This basically means: "added" implies a user must take an action (opt-in) to leverage something new, whereas "changed" implies the user automatically gains the improvement, provided they are already using related functionality. I think this semantic difference is very useful for our users. I'd like to see us improve the changelog with more metadata—specifically, a module / category / component (multivalued). ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
