We should have an EOL policy as it stands we make breaking changes to Jenkins where plugins that have not been released recently are effectively disregarded. We need to set a clear line where we believe its ok to break a plugin which can perhaps be part of this EOL policy.
For an EOLed plugin we could use a similar approach to plugin adoption. Where the maintainer has the option of now fixing up the possible problems with the plugin and release a new version. Which would reset its EOL countdown. Cheers, Raihaan On Tuesday, 27 April 2021 at 15:29:46 UTC+8 [email protected] wrote: > Oh, and: given the nature of our project, I think defining a clear way to > un-EOL a plugin would likely be needed too. > It's probable that we'll EOL some plugins, and after say 1 or 2 years some > folks will want to revive some of the plugins that got EOLed. > > It may seem backward, but I think it's a healthy thing. The bottom line > and expectation is that anyway we'll probably EOL dozens of plugins quickly > and only a handful will be requested to be unEOLed (meaning, after a > transitional pre-EOL warning period and nobody has complained during this > one). > > -- Baptiste > > Le mar. 27 avr. 2021 à 09:24, Baptiste Mathus <[email protected]> a écrit : > >> I agree this is an initiative definitely worth pursuing. We all know this >> is a pain. >> >> On criteria for defining whether a plugin should be EOLed, I think the >> best idea I have seen so far was Stephen's: >> >> https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/jenkinsci-dev/Ih0RviQ0G90/NmoVJQ1j6NAJ >> >> Basically automated regular PRs allowing for a global detection of >> plugins without an active maintainer. >> That maintainer's existence/reactivity + some criteria TBD (like last >> release date, the number of open jira issues, etc.) would help us decide >> whether or not start an EOL process. >> >> Anyway, however we define these criteria, which discussion I think we can >> handle separately, defining an EOL process I think has become vital indeed >> for the Jenkins Project to keep thriving. >> >> >> Le mar. 27 avr. 2021 à 04:00, Basil Crow <[email protected]> a écrit : >> >>> Abandoned plugins cause friction for both Jenkins users and contributors >>> alike. >>> >>> They cause friction for users because they are unlikely to be simpatico >>> with newer features like Pipeline. In the worst case, they are downright >>> incompatible with newer features like Configuration Form Modernization >>> and cause breakage that is difficult for users to resolve. >>> >>> They cause friction for contributors by making it difficult to perform >>> project-wide changes, such as Configuration Form Modernization or >>> dependency updates. >>> >>> True, distributing as many plugins as possible for as long as possible >>> maximizes the value the project provides and maintains the project's >>> strong reputation for flexibility. Yet, treating abandoned plugins as >>> first-class citizens indefinitely carries a non-trivial cost, and that >>> cost only increases the longer a plugin remains abandoned. >>> >>> The project is over 15 years old, and some plugins have been abandoned >>> for the better part of a decade. Many of these plugins will likely >>> remain abandoned for the next decade. At what point does the cost of >>> carrying these plugins outweigh the benefit? >>> >>> I do not know the answer, but I do know that the answer is not "never". >>> Contributor bandwidth is a finite resource. However, there remain >>> hundreds of plugins that have been abandoned for the better part of a >>> decade yet are seemingly presented as first-class citizens without so >>> much as a deprecation notice. This does not seem sustainable. >>> >>> I would like to propose that we define a process for plugin end-of-life: >>> initially marking such plugins as deprecated, then eventually removing >>> such plugins from distribution. >>> >>> How would we decide when to deprecate a plugin or remove it from >>> distribution? We could use metrics such as the number of days since the >>> last release and the number of installations. For example, we could >>> declare that any plugin that has not been released in five years would >>> be automatically deprecated and that any plugin that has remained >>> deprecated for more than five years would be removed from distribution. >>> We could put escape hatches in place to exempt sufficiently popular >>> plugins from this policy. >>> >>> I do not have a strong preference as to how long the support window >>> should be. But I do have a strong preference that it be finite: >>> supporting an unbounded number of plugins as first-class citizens for an >>> unbounded amount of time does not seem sustainable. >>> >>> I can already hear Oleg calling for a blog post to be written announcing >>> such a policy months in advance of its implementation, were such a >>> policy to be agreed upon. That would be fine by me as well. Again, the >>> point is not to be overly aggressive or to surprise users, but rather to >>> put reasonable limits in place that support the project's long-term >>> goals given the finite resources that are available. >>> >>> -- >>> 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/CAFwNDjoNMRbkDdkcjYMZSauCfE%2BRQ6pkv_jGG5W2RTqaDiJM2w%40mail.gmail.com >>> . >>> >> -- 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/bffbe5bb-9e12-4e45-8ae0-884704e68486n%40googlegroups.com.
