Re: 2.426 as Nov 15, 2023 LTS baseline?

[Mark Waite]

Tim Jacomb, can you confirm that 2.426 is approved as the next LTS baseline?

Thanks,
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/78b4cbe6-824e-4d9f-b561-37323b0a1b24n%40googlegroups.com.

Re: Backporting for LTS 2.414.3 has started

['Alexander Brandes' via Jenkins Developers]

I would like to propose backporting a documentation change [0], ensuring the 
installation pages match the instructions on jenkins.io .

Additionally, a remoting PR has been labeled as “backporting-candidate”.

[0] https://github.com/jenkinsci/packaging/pull/435
[1] https://github.com/jenkinsci/remoting/pull/675

> On 2. Oct 2023, at 14:36, Kris Stern  wrote:
> 
> Yes, my apologies, should be something like 
> https://issues.jenkins.io/issues/?jql=labels%20%3D%202.414.3-fixed instead, 
> otherwise the first issue looks like they don't belong. 
> 
> Best,
> Kris
> From: 'Jesse Glick' via Jenkins Developers 
> Sent: 02 October 2023 19:50
> To: jenkinsci-dev@googlegroups.com 
> Subject: Re: Backporting for LTS 2.414.3 has started
>  
> On Mon, Oct 2, 2023 at 1:49 AM Kris Stern  > wrote:
> Fixed: 
> https://issues.jenkins.io/browse/JENKINS-71479?jql=labels%20%3D%202.414.3-fixed
> 
> I think you meant to link to 
> https://issues.jenkins.io/issues/?jql=labels%20%3D%202.414.3-fixed ? 
> -- 
> 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-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1Jdikfn8nTNjYaVu-zih0m9Nzv3JTLiuei-WFy_AcssA%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 jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/OS3P286MB14314EC918E02F8A6779B887A1C5A%40OS3P286MB1431.JPNP286.PROD.OUTLOOK.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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/34CD8CDC-C3FE-4581-97EE-2E40544FF027%40notmyfault.dev.

Re: Splitting a plugin into a legacy and supported part

['Jesse Glick' via Jenkins Developers]

On Fri, Oct 13, 2023 at 2:38 AM Ullrich Hafner 
wrote:

> there might be still some users that use the old and deprecated steps
>

Like, Pipeline steps? So you cannot confidently delete this code without
potentially breaking user workflows?


> Move the old code to a new plugin with new plugin id. Make that new plugin
> a dependency of the code-coverage-api plugin.
>

I think this is backwards—then you are permanently locking the deprecated
code into the dependency chain.

`workflow-cps-global-lib-plugin` originally contained an in-Jenkins Git
server that you could push Pipeline Groovy libraries to. Later we added an
option to pull libraries from the SCM of your choice, and deprecated the
original code, but it stuck around and was a maintenance burden. So finally
we introduced `pipeline-groovy-lib-plugin` containing just the newer code
(in the same package structure and everything), made
`workflow-cps-global-lib` depend on `pipeline-groovy-lib`, and deprecated
the whole `workflow-cps-global-lib` plugin. Thus existing servers with
`workflow-cps-global-lib` installed would upgrade plugins, which would
automatically install `pipeline-groovy-lib` as a dependency, but see no
behavioral change. Admins could then at their leisure uninstall
`workflow-cps-global-lib` assuming they were not in fact using the old Git
server. New servers need never install `workflow-cps-global-lib` to begin
with (no longer a dep of `workflow-aggregator` or otherwise offered in the
setup wizard, etc.).

-- 
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1%2B2s9Ry%2BTU8y8h5ANST%2BZLyA9SpZuGNwJAt5D8PDdHFA%40mail.gmail.com.

Re: Splitting a plugin into a legacy and supported part

['Daniel Beck' via Jenkins Developers]

On Fri, Oct 13, 2023 at 8:38 AM Ullrich Hafner 
wrote:

> Or is there even anotheroption that I do not see?
>

Depending on the scope of the problem, deprecation and finally removal of
the obsolete stuff you want to remove.

Use usage-in-plugins to identify callers and consider providing PRs with
the necessary changes for the more popular ones (and consider how much you
care about non-public plugins).

Specify hpi.compatibleSinceVersion in the pom to tell admins that the new
release is incompatible with older ones, and write a useful changelog.

-- 
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKf6UVsE%3DSgePdfmMY6RqANSraJYfbrr2MWdd%2BCEzX1uw%40mail.gmail.com.

Splitting a plugin into a legacy and supported part

[Ullrich Hafner]

Hi,

I want to retire a lot of old and legacy code in the code-coverage-api plugin 
in order to simplify the development experience (e.g., there are duplicate 
classes and jelly views). It is difficult for new contributors to start 
development when they do not know which classes and views are actually still 
used. Since there might be still some users that use the old and deprecated 
steps I am wondering how to do that in the best way.

1) Move the old code to a new plugin with new plugin id. Make that new plugin a 
dependency of the code-coverage-api plugin. Benefits: Everything is out of 
sight, not-used dependencies can be moved as well. Clean restructuring of the 
plugin.
2) Move the old code to a different source folder. Maven does support that but 
I am not sure if our maven-hi plugin does. Benefits: no new plugin is required, 
but dependencies need to be shared for both parts of the code.
3) Move the old code to a maven sub module in a new folder. Maven does support 
that but I am not sure if the rest of our build infrastructure does.

Or is there even anotheroption that I do not see?

My favorite is option 1), but that requires to create a new plugin in the 
jenkinsci organization.

Ulli 

-- 
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/5D44F363-6A45-4430-B82F-581CF815E14B%40gmail.com.