On Mon, Oct 19, 2015 at 9:13 AM, James Nord <
jn...@cloudbees.com> 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