Plugin end-of-life (EOL) policy

[Basil Crow]

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.

[Baptiste Mathus]

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.

 

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjoNMRbkDdkcjYMZSauCfE%2BRQ6pkv_jGG5W2RTqaDiJM2w%40mail.gmail.com.

[Baptiste Mathus]

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

[raihaan...@gmail.com]

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

[Oleg Nenashev]

I definitely support having a policy for putting for adoption, deprecation and then removal. Before we introduce this policy, I would like to firstly introduce a concept of the "company/team owner" so that we could distinguish plugins maintained by company contributors and contact companies instead of individuals who might have left their employer via inactive emails. After we do so, +100 for setting up a policy as long as there are manual gates for the community approval. Some plugins "just work" afterall, and maintainers may not need to deliver patches.

I would propose the following:

• The plugins will be put for adoption after 1 year of maintainer inactivity, if there are open pull requests without changes requested by maintainer (approved but not merged OR unreviewed). If possible, GitHub maintainers should do the best effort attempt to reach out to the maintainer (GitHub ping and email if available in pom.xml or Jira). Adoption is marked via the "adopt-this-plugin" topic in GitHub and propagated to the update center. To recover from this stage, the Plugin Adoption process is applied
• The plugin may be marked as deprecated after 1 year in adoption OR once there are known unresolved breaking changes in the Jenkins weekly baseline. To recover from this stage, there should be plugin adoption. Deprecation is marked via the "deprecated" repo topic in GitHub and propagated to the update center.
• After 6 months of being deprecated, the plugin may be depublished. The source code will be archived in this case. To recover from this stage, a plugin needs to be adopted by the maintainer and then released as a new version. After that, it may be restored by a pull request to the update center repo

Multi-plugin repositories might be managed by the same process, because all of them will be put for adoption or depublished at once. Deprecation is a bit trickier, but we have a way to control that in the update center metadata if needed.

For such a process, it would be also great to finally support the tombstone pages for depublished plugins on the plugin site. They could provide plugin users with information about how to step up and to recover the plugin.

Best regards,

Oleg Nenashev

[Arnaud Héritier]

I love all these proposals and I'll support them.

What is clearly important is to have some well defined rules and if potentially to automate as much as possible the processes required to follow the plugins lifecycle.

I am not sure if it could make sense or not, but could we have some cases (plugins used as library maybe?) where not having any (or a lot) of activity could not be an issue ?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9a95b122-46d7-489c-8a87-a292eed23d71n%40googlegroups.com.

--

Arnaud Héritier

Twitter/Skype : aheritier

[Oleg Nenashev]

Hi Arnaud,

One if the options would be to set a borderline quality/devtools requirement. For example, we can say that a plugin "must use Plugin POM 3.7 or above" (Java 11 devflow for Maven, ??? Gradle) or "a plugin should be built and tested against Jenkins 2.7.1 LTS at least". Such a requirement should cover almost all active and "active" plugins.

BR, Oleg

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/9M2B6ZTKjI0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-9pOooHOaBkOTLZdyOgDKSnXLXH1b6J6cRC%3DZPZPL51aA%40mail.gmail.com.

[Arnaud Héritier]

Good ideas. 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLA8du0_%3DcbEnvDiGyBtVfYe0kieQV1BBsPH%2B%3DW2CENQ4A%40mail.gmail.com.

[Daniel Beck]

On Tue, Apr 27, 2021 at 4:00 AM Basil Crow <m...@basilcrow.com> wrote:

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.

How was the config form change impacted by this specifically?

It seems that we get the most complaints recently (i.e. once actively maintained plugins were identified and fixed) about that change for a plugin with unresolved security issues that we're not currently distributing, TFS. It doesn't look like this proposal would help here.

Doing this also means we commit to "support" (whatever that means) anything not deprecated. I am not sure we want that.

A major reason I added the release date to the UI on the plugin manager is to highlight to admins that they're (considering) using likely obsolete software. We're not (yet) exposing popularity on the UI other than for sort order, but the plugin site does. Between the two, it seems to me we give admins the tools they need to determine whether they want to continue using plugins that are likely unmaintained, and in case of problems they're likely to be the first ones (low install count).

I would prefer if we'd consider a more expressive system for plugins metadata. We added 'deprecated' and 'adopt-a-plugin' labels to core recently, but every new label like that needs dedicated support. Something more extensible, with version ranges like we do for security warnings could help here:

"This plugin is likely to break the UI once you update Jenkins to 2.277.x" and "no fix is available" or "update to version X or newer". Then admins can decide for themselves if they want to continue using the plugins. That's how we're doing it at the moment with unresolved security vulnerabilities except in the most egregious cases. If we do this generically enough we can reuse it whenever a similar issue comes up.

Then the only thing different is the larger plugin ecosystem we would want to check for compatibility issues, but if that's sufficiently well automated (there'll still be many hundreds of plugins left!), it shouldn't make a huge difference. On the pro side, we don't annoy admins for no real reason because we stop distributing their pet plugin that has worked without problems for years.

If we go ahead with this proposal however, implementation-wise, we need to consider the following:

How would you handle plugins that are actively maintained but the maintainers don't care about the problems enough to address them? Some plugins are "maintained" by folks happy to merge PRs and create new releases, and that's all they do. What really is the difference between that and having contributors implementing large scale projects get maintainer permission temporarily to merge and release their own PR? And would such a one-off release reset the deprecation clock?

How would you deal with plugin dependencies? Deprecation should be transitive while the dependency exists, because you cannot install a dependent plugin without the plugin it depends on being available.

jquery-ui was last released in 2011 and role-strategy had a dependency on it for most of 2019, catapulting jquery-ui's popularity. In 2019, would you have suspended distribution of jquery-ui, breaking everyone on recent releases of role-strategy?

Or, for an ongoing potential issue: If you install Jenkins today and install suggested plugins, you also install these through dependencies (dates are their latest releases):

2016-03-03T12:08:37.00Z - momentjs
2016-03-03T12:09:31.00Z - ace-editor
2017-01-16T17:29:02.00Z - pipeline-github-lib

Dependent plugins are workflow-cps and pipeline-stage-view (selected via workflow-aggregator). I don't think automatically marking the Pipeline plugin suite deprecated, as some recent responses to this thread recommend, helps anyone.

[Jesse Glick]

On Mon, May 3, 2021 at 3:46 AM Daniel Beck <db...@cloudbees.com> wrote:

Something more extensible, with version ranges like we do for security warnings could help here:

"This plugin is likely to break the UI once you update Jenkins to 2.277.x" and "no fix is available" or "update to version X or newer".

FYI https://issues.jenkins.io/browse/JENKINS-49651 

[Oleg Nenashev]

I tentatively put the topic to the tomorrow's governance meeting agenda: https://docs.google.com/document/d/11Nr8QpqYgBiZjORplL_3Zkwys2qK1vEvK-NYyYa4rzg/edit#heading=h.1gtco63t6ztr

We will discuss it if there are the stakeholders from this thread and enough time left.

[Manuel Ramón León Jiménez]

I'm in for this proposal. We need a way to clean up the ecosystem to be able to progress easily without investing too much on things that are not used.

We can discuss and polish the details, but the aim remains the same. 

Thank you Oleg for triggering the discussion.

--

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 jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9c82d2f8-4f8a-4cf2-b1a1-ea8247c8e530n%40googlegroups.com.

[Oleg Nenashev]

> Thank you Oleg for triggering the discussion.

Credits go to Basil :) We had the discussion about EOL/adoption policy plugins multiple times, and I am totally in favor of getting it over the line.

Maintaining the current status quo is a disservice to Jenkins users

[Basil Crow]

To be honest, I was a bit taken by surprise at the intensity of the
discussions regarding this topic. I was expecting that we could all
agree on some basic criteria, publish a simple statement to that
effect on jenkins.io, and refer to that policy as necessary while
doing work on new features or dependency management. I did not have it
in my mind to write any automation, let alone to introduce "a concept
of […] company/team owner so that we could distinguish plugins

maintained by company contributors and contact companies instead of
individuals who might have left their employer via inactive emails"

(which was explicitly stated as a prerequisite to adopting a plugin
EOL policy). All of this sounds like a large amount of bureaucratic
work, and as a volunteer I have neither the time nor the interest in
pursuing matters of corporate governance. Moreover, I consider it
unlikely that such an approach would be practical.

As a tech lead, I know that making one large and complex deliverable
depend on another large and complex deliverable is likely to result in
delivering neither. My experience is that an incremental approach
works better. My suggestion to the Jenkins community is to focus on
identifying incremental steps to improve the status quo without
getting sidetracked with large and complex deliverables (and
correspondingly lengthy debates). As Bryan Cantrill writes: "When
faced with a decision, determine if there are elements that are common
to both paths, and implement them first, thereby deferring the
decision." One example of such an incremental step forward was my
recent PR to deprecate a handful of older plugins. The more
incremental steps like this we take, the clearer the target becomes.
The target might seem blurry and distant at the beginning, but after
enough steady progress it will come into focus. When that delightful
moment occurs, debate will be pointless since we will be more excited
about racing to the finish line, together.

To the extent that I can identify incremental steps forward, I will
continue to propose them. I believe this is an important challenge for
the Jenkins project, and I want to be a part of the solution. I will
continue to try and help where I can, as my time allows.