The procedure of core deciding when and what split plugins to install looks good. My take on Jenkins.version field is bit different that I think there will be a lot of people who haven't touched the system config for quite some time, which means it cannot be used as a reliable indication of what version was running immediately before the upgrade. But it does tell you what version have run in the past, so it's still useful as a conservative indicator, and if we have to err between breaking people's upgrade by not installing the right split plugin vs installing extra plugins, we'd be obviously choosing the latter.
So the end result is the same as what we are all saying. 2015-08-19 5:55 GMT-07:00 Jesse Glick <[email protected]>: > 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. > We have to do the "plugin selection wizard" in Tom's picture (aka the proper solution of JENKINS-9598) first before removing bundled plugins. If we do the latter first without former, new user experience gets even worse. I believe that's a mistake. -- Kohsuke Kawaguchi -- 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/CAN4CQ4z5tENHjKNgjAQpRPuzDgVv8pDzA8VgmKnPGyx8TBfTyQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
