We have the JobConfigHistory plugin installed and configured to dispose of historic changes older than 30 days. Recently we noticed that when a job does not undergo changes for an extended period of time, the plugin will delete all historic changes except the very first change when the job was initially created.

This is quite different than the logic found in, say, the build log retention policy provided by Jenkins natively. By comparison, when using a similar set of options, this logic will delete all historic logs except the latest one.

The behavior of the latter seems much more intuitive and useful.

Example Use Case
Suppose you create a new job, and spend the next week or so making adjustments to the configuration to correct bugs and such with the job. Now suppose you don't touch the job for 6 months, after which you find yourself needed to make a change to the job configuration. Further, after making this change you discover that your changes do not work and you want to revert back to the previous state. To do so you open the jobs configuration history only to discover that there are only 2 historic states available to choose from: the one tracking the change you just made, and the one from the original creation of the job. So basically now there is no way for you to revert your changes to the state that existed just prior to your most recent change.

Recommendation
When deleting obsolete job configurations from the history, it would be much more beneficial to preserve the most recent change from the history and delete all prior changes than it would be to delete the most recent changes and preserve the original one when the job was initially created.