{subsection:What should a version history entry be like?}
-It should be concise, clear, english prose. It should be just enough info for a user or admin to have an idea of the kind of change, so they can decide if they care enough about it to upgrade their pool. It should not include any developer jargon, or refer to internals of the Condor source (not for "security reasons, but because most people reading this won't know anything about our source, even if we were really open). If it's a bug-fix, include the version where the bug was introduced (if you know). It can (and often should) include pointers into other parts of the manual where you document the new config knob, explain the new feature, etc. If you fix a bug in the file transfer code, it doesn't hurt to include the line: "For more information about Condor's file transfer capabilities, see section~\ref{sec:file-transfer}".
+It should be concise, clear, english prose. It should be just enough info for a user or admin to have an idea of the kind of change, so they can decide if they care enough about it to upgrade their pool. It should not include any developer jargon, or refer to internals of the Condor source (not for "security reasons," but because most people reading this won't know anything about our source, even if we were really open). If it's a bug-fix, include the version where the bug was introduced (if you know). It can (and often should) include pointers into other parts of the manual where you document the new config knob, explain the new feature, etc. If you fix a bug in the file transfer code, it doesn't hurt to include the line: "For more information about Condor's file transfer capabilities, see section~\ref{sec:file-transfer}".
Immediately before the entry, include the GitTrac ticket number or numbers and optionally any relevent commit IDs. If you don't have a GitTrac ticket number, 1) why not create a ticket and use it? but 2) the commit ID becomes mandatory. Here is an example:
