On Friday, December 31, 2021 at 6:56:04 AM UTC-7 reda wrote:
> Hi Mark, > > Thank you for your answer. > > The compatibility breakage instructions are about persisted data. Is there > something equivalent for binary compatibility? > > When the compatibility guidance in the governance document says: > we also recognize that plugin developers expect APIs and other code that they depend on to remain available in future versions of Jenkins I think that applies in this case that you are considering. However, the later phrasing states that compatibility breaks are allowed but are done carefully. Some examples of carefully done compatibility breaks have included the upgrade from the Jenkins fork of xstream to the standard release of xstream and the upgrade from Guava 11 to the current release of Guava. Both those improvements arrived in Jenkins core within the last 12 months. In both those cases, the developer took the same steps you are taking. Plugins were checked for compatibility. Plugins were updated to be compatible with the new version where feasible. In some cases, it was accepted that the plugin would not be updated because it was not being actively maintained and had a small number of installations. If you can't reasonably maintain API compatibility, then I believe you have done the right thing to check that there are no known downstream dependencies on the plugin you are changing. Mark Waite > -- 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/c049db11-6a36-4263-93be-bbbbdca241b4n%40googlegroups.com.
