On Mon, Oct 19, 2015 at 9:13 AM, James Nord <[email protected]> wrote: > there shall not be any use of the bytecode-compatibility-transformer and > @AdaptField.
I see your point; this looks very scary, and we clearly do not have any JVM experts on hand to design a system that is truly foolproof. (Or sufficiently powerful—`@AdaptField` only helps with a very limited set of problems, and if we want to continue splitting plugins from core¹ we need a lot more.) On the other hand we are looking at the potential for a *lot* of `LinkageError`s hitting innocent users during an upgrade. I wonder if we can find some more static, debuggable, easily understood procedure for solving this class of problem. For example 1. Deprecate things we do not want people using and introduce replacements. (As soon as possible—not waiting for 2.0.) 2. Provide a precise, perhaps mechanically enforceable refactoring. NetBeans declarative refactorings² are better than nothing, though I would like to see a batch-mode tool (+ Maven plugin) to apply them. 3. Enhance `plugin-compat-tester` to check for deprecation warnings when compiling against the newest dependency, or otherwise find usages of members we propose to delete. Have a team responsible for finding & fixing failures, if necessary incrementing the plugin’s baseline version to get access to the replacement. 4. Introduce a facility to the Jenkins plugin/update system allowing us to declare that a specific version of the plugin is the first known to be compatible with a specific version of a (core or plugin) dependency. If you attempt to upgrade the dependency you will be blocked unless you also agree to update the dependent. ¹https://issues.jenkins-ci.org/issues/?jql=resolution%20%3D%20Unresolved%20and%20labels%20in%20(split-plugins-from-core) ²Example: https://github.com/jenkinsci/jenkins/blob/3d2956d9ad65e34cc74949e5b397b7475c6cb04b/core/src/main/resources/META-INF/upgrade/AbstractTestResultAction.hint -- 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/CANfRfr105YojNuJrpOt2a3sCWrAVbSnLoMY3aF-SM312M2_0_A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
