Hi Mark, Thank you for your answer.
The compatibility breakage instructions are about persisted data. Is there something equivalent for binary compatibility? On December 31, 2021, Mark Waite <[email protected]> wrote: > > On Fri, Dec 31, 2021 at 6:14 AM 'Réda Housni Alaoui' via Jenkins > Developers <[email protected] <mailto:jenkinsci- > [email protected]>> wrote: > Hi all, > > I am currently in the process of refactoring sonar-gerrit-plugin. > > There are some constructor and getters/setters that I would like to > get rid of. Removing them would only break dependent plugins. > > Looking at <https://plugins.jenkins.io/sonar-gerrit/#dependencies>, I > do not see any public dependent plugin. > What's the policy in this kind of situation? > > Should I go ahead and potentially break compatibility with private > dependent plugins? > > Or should I try to preserve binary compatibility? If yes, is there any > point in time where it will be ok to remove deprecated elements? > Based on the compatibility phrasing in the project governance document > <https://www.jenkins.io/project/governance/#compatibility-matters>, I > think you should do your best to retain compatibility. It says: > We recognize that users expect their existing data, accumulated under > past versions [...] to continue working under future versions of > Jenkins. This includes jobs configurations, build records, and plugin > binaries that they are using. The Jenkins project places high value on > maintaining this compatibility, and will be very careful in removing > functionality. > > To enable the above goal, we also recognize that plugin developers > expect APIs and other code that they depend on to remain available in > future versions of Jenkins. This is not to say we don’t ever remove > anything, but we do it very carefully. > > Because one plugin can depend on another, we expect the same principle > from plugins that many other plugins depend on. > That doesn't forbid you from breaking compatibility, but it does > prefer to preserve compatibility when you can. > If you find that you must break compatibility, please follow > instructions in the developer guide > <https://www.jenkins.io/doc/developer/plugin-development/mark-a- > plugin-incompatible/> to note the version that includes the breaking > change. > 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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/f747ff84-af8a-4503- > 8159-df3e55e55874n%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/f747ff84-af8a-4503- > 8159- > df3e55e55874n%40googlegroups.com?utm_medium=email&utm_source=footer>. > -- > You received this message because you are subscribed to a topic in > the Google Groups "Jenkins Developers" group. > To unsubscribe from this topic, visit > <https://groups.google.com/d/topic/jenkinsci- > dev/P9A90864Tqw/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > [email protected] <mailto:jenkinsci- > [email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci- > dev/CAO49JtF4eypOsUtuqhp_riq4f%3DLPPSQab510WSMz%3Dh3RfurWiw%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci- > dev/CAO49JtF4eypOsUtuqhp_riq4f%3DLPPSQab510WSMz%3Dh3RfurWiw%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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/61a5fa54a04b9ab05be34ebfa6d59b5ac473911a%40hey.com.
