Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-47393] Remove signature and runtime references to CommandLauncher #79

Merged
merged 1 commit into from
Oct 17, 2017

Conversation

jglick
Copy link
Member

@jglick jglick commented Oct 11, 2017

For jenkinsci/jenkins#3076.

@reviewbybees

@ghost
Copy link

ghost commented Oct 11, 2017

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

jglick added a commit to jglick/jenkins that referenced this pull request Oct 11, 2017
Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to do the change in a compatible way, e.g. by introducing bridge methods and requiring the detached plugin to be installed?

The change introduces a breaking change in the JTH library, and IMHO it needs to be justified at least

@jglick
Copy link
Member Author

jglick commented Oct 17, 2017

introducing bridge methods

Oh no.

introduces a breaking change in the JTH library

Unlikely to be source-incompatible (not that we care greatly), and binary incompatibility is irrelevant.

@jglick jglick requested a review from oleg-nenashev October 17, 2017 14:03
Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Binary compatibility may be important for things like PCT, which probably bump JTH. But I agree it's not a blocker for the test framework (though it may cause fun for plugins shipping tests artifacts).

The code itself LGTM, hence 🐝

@jglick
Copy link
Member Author

jglick commented Oct 17, 2017

things like PCT, which probably bump JTH

AFAIK it does not. That was in fact one of the benefits of splitting jenkins-test-harness into its own repository and giving it an independent lifecycle: that a plugin POM could declare a specific jenkins-test-harness.version which would remain consistent even when running with a newer jenkins.version during something like PCT (or jenkinsVersions of buildPlugin, etc.).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants