On Tue, Aug 18, 2015 at 5:01 PM, Tom Fennelly <[email protected]> wrote: > could we use a simple plugin that needs to be installed that captures and > records all split > plugin info from the instance. This info can then be used on the subsequent > install so as to install the exact versions of split plugins. An upgrade > would be aborted if that info was not present during startup. Or is there a > better way or existing info that can be used?
I thought I already proposed everything that was needed here. You know the version of Jenkins that was running before the upgrade (with the caveat below). From that and the static list in `ClassicPluginStrategy` you can compute which plugins were part of core before the upgrade and have since been split off. Those are the ones that must be installed now to prevent a regression. Any plugins that were previously bundled will still be there in `$JENKINS_HOME/plugins/*.jpi` so those will still be loaded, unless the user disabled them. The caveat: you actually know the last version in which global configuration was saved (if 1.301+), which is probably close to the last version run. If they differ, the last-saved version was very likely older than the last-run version—since downgrading core does not generally work anyway—so at worst we wind up listing a plugin which was split in between those two versions. But such a plugin would have been bundled in the later version, and thus already in your plugins directory, so we can simply skip over it. So if the user runs with a fresh `$JENKINS_HOME`, they get zero plugins, but we can add a wizard or whatever UI to make recommendations. If on the other hand they last ran 1.532.x, they would have had some bundled plugins, including the splits prior to that point (…, `ldap`, `pam-auth`, `mailer`). They might have upgraded or disabled some of them. After the upgrade, the plugins they were running before remain in the same state, except that previously bundled plugins are just plain old installed plugins now (any `*.jpi.pinned` markers will just be ignored). Furthermore, during startup we automatically install `matrix-auth`, `windows-slaves`, `antisamy-markup-formatter`, `matrix-project`, and `junit` (getting these from `WEB-INF/optional-plugins/*.hpi` where the module Stephen mentioned looks for them): again, just as plain old installed plugins, which the user could subsequently choose to disable or even uninstall completely. Thereafter Jenkins will not touch your plugin list, unless we split another plugin from core and you upgrade past the split point: to make the upgrade as transparent as possible, we again silently install that plugin. `jenkins.war` would get slightly smaller, as the few plugins which were previously bundled but not split or a dependency of a split (I think just `ssh-slaves` and `translation`?) are removed. As features are refactored into split plugins it should stay about the same size. We could consider removing some very old and bulky splits (like `maven-plugin` and `subversion`, the two oldest and bulkiest!) to make the WAR 21% smaller; people upgrading directly from Hudson (!) 1.309 or earlier could still have these plugins automatically installed during startup so long as they were connected to the Internet. Anyway, this is all just a technical proposal, contingent on agreement with the basic goal of not having bundled plugins any more. I did not get the impression that Kohsuke is really on board with that. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1EXyEqC%2BYnQMB0Z_J7cBWQinifF6qO%2BCRHvwK45k7Dxw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
