On Fri, Aug 14, 2015 at 5:51 PM, Kohsuke Kawaguchi <k...@kohsuke.org> wrote: > when a plugin is split from core in version X, people upgrading > from a version earlier will experiene functionality loss.
Well I think this is what we should be spending a little effort fixing. IMO there be *no* bundled plugins, so a new installation (virgin `$JENKINS_HOME`) has no enabled plugins. The question is how to deal with upgrades. We are already tracking split plugins by version https://github.com/jenkinsci/jenkins/blob/fd83a285b3b1560ba19122ff33edc522de7027f0/core/src/main/java/hudson/ClassicPluginStrategy.java#L324-L337 but so far we only use this for implicit dependencies. We also track last-saved version, a close proxy for last-used version https://github.com/jenkinsci/jenkins/blob/fd83a285b3b1560ba19122ff33edc522de7027f0/core/src/main/java/jenkins/model/Jenkins.java#L318-L330 so we should able to determine which split plugins the user expected to be installed. So we should install those, and only those, during the first startup after the upgrade: 1. We could try to load them from the update center. This would be vulnerable to dropped Internet connections and so on, however. 2. Or, Stephen Connolly wrote a system allowing plugins to be bundled as “optional”, and only conditionally enabled during startup. So the WAR download size would remain large, but you would not see plugins enabled unless you were upgrading from a version before they were split. With this fixed, the problem reduces to helping novice users pick reasonable plugins. -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr09ek0W5HhxHf6Vo2a4zcVSq-tbMYLBD9Pyf6HYr_5Xqw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
