We recently upgraded our Jenkins LTS instance from v1.532.3 to the latest 1.609.1 version, after which we discovered some critical defects that required us to roll back to the prior version, 1.596.3. In so doing we encountered issues loading build logs and such due to the incompatible configuration changes applied by 1.609.1. We proceeded to run the downgrade script as described here to no avail. The script appeared to have completed without error but it didn't actually apply any changes to the configuration.

Further ad-hoc testing reveals that one contributing factor is that we have set a custom path for the Jenkins logs on our master configuration (ie: ${JENKINS_HOME}\logs\builds\${ITEM_FULL_NAME}) and this seems to confuse the reverse migration script. To test my theory I moved a few of our build log folders out of our custom folder and into their default location under ${JENKINS_HOME}\jobs\ ${ITEM_FULL_NAME}\builds and then re-ran the downgrade script. All of the logs I had relocated were correctly downgraded to the old configuration, however none of the logs that were left under the custom log folder were touched.

Needless to say moving the build logs back to their default locations is tedious and error prone at best, and the effort is exacerbated by larger build farms like ours where we have well over 1000 jobs which would need to be migrated.

This, once again, puts us between a rock and a hard place. We are unable to continue using v1.609.1 due to failures to preserve backwards compatibility and if we downgrade to the previous version we are going to loose all of our build history, which is substantial - and of critical importance to our company - or we must incur significant expense to correct the issue ourselves.