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
> 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
On Wednesday, May 5, 2021
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.
On Tue, May 4, 2021 at 7:08
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.
On Monday, May 3, 2021
On Mon, May 3, 2021 at 3:46 AM Daniel Beck 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".
>
On Tue, Apr 27, 2021 at 4:00 AM Basil Crow 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
>
Good ideas.
Le dim. 2 mai 2021 à 21:03, Oleg Nenashev a écrit :
> 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
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
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
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
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
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
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:
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
14 matches
Mail list logo
