> > > A few things here: > * perhaps we need to shade in the Github library into each plugin that > requires it. Avoid version hell altogether > * start versioning the Github library so it's clear when there are major > breaking changes between versions. Stephen C does an excellent job at this > for all the branch and scm API changes. > > This library is claimed as backward compatible by KK (okhttp isn't updated and User/Org difference isn't implement also because of this) , that's why it wrapped into jenkins plugin and used by all other plugins. While i were maintaining gh-api-plugin and gh-plugin i were checking them before releases (until few devs started doing changes without approval violating project rules, but it other story) and found broken binary compatibility few times. It was caused by Kohsuke's "maintaining style", or simply saying merge everything, make changes in one evening and release few minutes later. So some projects using direct library dep may hit incompatibilities between available gh-api-plugin versions. In theory breakage shouldn't happen, but if somebody depend directly on library, then it should shade it or play by jenkins classloaders rules and use plugin wrapper. Even today there are issues with this library, so probably it even makes sense to starting thinking on using some other library or fork it.
For those who requested support and eclude abstract discussions, please provide https://wiki.jenkins.io/display/JENKINS/How+to+report+an+issue#Howtoreportanissue-WhatinformationtoprovideforEnvironmentandDescription -- 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/4c784a1b-6bf2-4057-bd04-7ac9c10c37d7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
