Releasing a plugin (for SVN)

[Maciej Jaros]

Hi

So, I got approved and successfully adopted a plugin (the SVN/Subversion plugin). I've added some features / fixes, and now I'm wondering how to release it. Or what is the process of releasing plugins in general? Mostly from the human side of things.

Is this usually done by plugin maintainers themselves, or by Jenkins employees, or perhaps simply more experienced volunteers handle releases? Is it customary to wait for other devs to +1 a release or something like that?

I mean I know technically there are actions that build a draft release (I see it in the releases), so the "Release Drafter" works. Dependabot and automatic versioning seem to work too. I see that cd.yaml is running daily. So all technical stuff described in the docs seems already configured. So it is only the final steps that are not clear to me: final tagging, procedure/customs for publishing a release on Github and who and how pushes this to Jenkins plugins.

I'm not planning to release the plugin just yet, as I'd still like to test it for a while on a larger Jenkins installation. I'm just slowly getting ready for a release, perhaps next week if possible.

Regards,
Maciej Nux
(Eccenux on Github)

[Daniel Beck]

On Fri, Sep 4, 2026 at 12:58 PM 'Maciej Jaros' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

Is this usually done by plugin maintainers themselves, or by Jenkins employees, or perhaps simply more experienced volunteers handle releases? Is it customary to wait for other devs to +1 a release or something like that?

As a maintainer, it's up to you to decide whether and when to publish a release. Ideally only do that when you're confident it's in a good state, and are prepared to follow up if it's not.

There is no such thing as a "Jenkins employee". Some people, including myself, have day jobs that involve contributing to the Jenkins project, but that's all.

 

I mean I know technically there are actions that build a draft release (I see it in the releases), so the "Release Drafter" works. Dependabot and automatic versioning seem to work too. I see that cd.yaml is running daily. So all technical stuff described in the docs seems already configured. So it is only the final steps that are not clear to me: final tagging, procedure/customs for publishing a release on Github and who and how pushes this to Jenkins plugins.

You have the default CD workflow configuration: A release is created when you trigger the workflow manually or when a PR with an "interesting category" label is merged.

Docs: https://www.jenkins.io/doc/developer/publishing/releasing-cd/#no-release-has-been-triggered-after-merging-a-pull-request

 

I'm not planning to release the plugin just yet, as I'd still like to test it for a while on a larger Jenkins installation.

This would indicate the current workflow is not set up for how you maintain the plugin, as it would release upon merging a PR with an appropriate label.

Daniel

CONFIDENTIALITY NOTICE: This email and any attachments contain confidential and proprietary information of CloudBees intended only for the named recipient(s). Unauthorized use or distribution is prohibited. If you received this in error, please notify the sender and delete this email.

[Maciej Jaros]

Hi.

[continues below]

 

I'm not planning to release the plugin just yet, as I'd still like to test it for a while on a larger Jenkins installation.

This would indicate the current workflow is not set up for how you maintain the plugin, as it would release upon merging a PR with an appropriate label.

I mean maybe... Everything I merged to main/master I consider to be good enough, but I prefer to do more testing on an actual Jenkins.

You have the default CD workflow configuration: A release is created when you trigger the workflow manually or when a PR with an "interesting category" label is merged.

Docs do seem to suggest that running CD build would release the plugin, but it doesn't seem like it works like that. There were multiple CD builds on GitHub, but the Subversion release is not yet available.

Two things suggest that it has not been released:

1. When I look at: https://plugins.jenkins.io/subversion/releases/ I see version 1303.x from 8 months ago.
2. I also see the same version (1303.x) in `/manage/pluginManager` on my installation.

So that is fine, but it also a bit confusing. I mean I'm still not sure how to do an actual release. Am I correct in assuming that once I finalise a release on GitHub (currently only a draft), it will be released to plugins.jenkins.io and users will be able to update via their Plugin Manager?

Cheers,
Maciej Nux

[Daniel Beck]

> On 4. Sep 2026, at 18:44, 'Maciej Jaros' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>
> Docs do seem to suggest that running CD build would release the plugin, but it doesn't seem like it works like that. There were multiple CD builds on GitHub, but the Subversion release is not yet available.… I mean I'm still not sure how to do an actual release.


The workflow running does not mean a release is being created. The conditions for a release to be created when the workflow is running are in my previous email. The linked FAQ ("No release has been triggered after merging a pull request") also explain it.

[Maciej Jaros]

Daniel Beck (2026-09-05 10:18):

>> On 4. Sep 2026, at 18:44, 'Maciej Jaros' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>>
>> Docs do seem to suggest that running CD build would release the plugin, but it doesn't seem like it works like that. There were multiple CD builds on GitHub, but the Subversion release is not yet available.… I mean I'm still not sure how to do an actual release.
> The workflow running does not mean a release is being created. The conditions for a release to be created when the workflow is running are in my previous email. The linked FAQ ("No release has been triggered after merging a pull request") also explain it.

OK, I think I got it now :). Manual CD build worked for me. Thanks!

Regards,
Maciej Nux