|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
1. That is the simplest way. However, if you want to preserve history, you'd need to revert to previous version of plugin, then turn off the Integrity CM. Upgrade to the new plugin and then re-enable the CM piece. This will allow you to keep history but reset the CM configuration data.
2. When you create multiple instances of the Integrity CM plugin (which happens when you use the Multiple SCM plugin) in a single Job, then there is only one Job name. In this case, I need to isolate each instance of the Integrity plugin (for the derby db) within the same job name. Hence the need for the parameter 'configuration name'. This way you can create multiple instances of the Integrity CM plugin within the same job and have separate derby dbs for each configuration/instance.
I'm currently working on creating a single Derby DB for all Jobs. So, while you can't get rid of the 'configuration name' parameter, if you want to defer an upgrade you might as well defer it to version 1.30.