GitBlit plugin backwards compatibility

[Carles Capdevila Tejada]

Hi there,

So I've developed the GitBlit plugin and it's now officially hosted.

The artifactId was gitblit-branch-source and I was recommended to rename it into gitblit following the naming recommendations of the scm-api plugin. By that time I did not know that this would, in the eyes of Jenkins, be a totally different plugin.

I developed this plugin for the company I'm working for and many (6-12) projects are using this, so I can't just make them create their organizations from scratch again with the newly renamed (artifactId=gitblit) plugin.

So questions are:

1- Is there any way at all that I can migrate the jobs from the old plugin to the new (artifactId:gitblit-branch-source -> gitblit)? I reckon not.

2- Is it OK if I leave the artifactId as gitblit-branch-source, when the official repository is called https://github.com/jenkinsci/gitblit-plugin?

3- Other suggestions on how to deal with this?

Thank you for your attention :)

[Oleg Nenashev]

Hi,

Sorry, I have missed this thread.

Is there any way at all that I can migrate the jobs from the old plugin to the new (artifactId:gitblit-branch-source -> gitblit)? I reckon not.

plugin name != classpath. As long as classpaths are the same, there should be no compatibility. There is a risk that two plugins get installed at once, and Jenkins admins will be responsible to manage it. The old plugin can be removed from update centers via a pull request to https://github.com/jenkins-infra/update-center2/blob/master/src/main/resources/artifact-ignores.properties

2- Is it OK if I leave the artifactId as gitblit-branch-source, when the official repository is called https://github.com/jenkinsci/gitblit-plugin?

IMHO it is not OK. But the repository can be easily renamed by any of organization admins. In this case GitHub will automatically redirect requests to the previous URL.

Other suggestions on how to deal with this?

As mentioned above, make sure you remove the old plugin from update centers

Hopefully it helps,

Oleg

[Jesse Glick]

On Sat, Aug 11, 2018 at 9:54 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> There is a risk that two plugins get installed at once, and Jenkins admins will be responsible to manage it.

Which you can make those “6–12 projects” do. All they need to do is go
the plugin manager, uninstall the old plugin from *Installed* (which
will prompt to restart—but do not), then select the new plugin from
*Available* and *Download now and install after restart* and agree to
restart to apply changes. When it comes back up, it should have only
the correctly-named plugin installed, and the existing organization
folders should be loaded without incident (assuming, again, you did
not change package names or anything).

Various other workflows will also suffice. Jenkins will not discard
the organization folder configuration even if it starts up without
either of the plugins loaded—only if you explicitly save the (broken)
configuration; it will just try again to load those class names next
time.

> The old plugin can be removed from update centers

From what I understand, the old plugin was never on any update
center—it is being newly hosted, under the new and correct name.

So assuming that the old plugin with the undesirable name is confined
to a handful of Jenkins servers that you can track down, please just
fix those, and do not bake the mistake into the Jenkins community for
eternity.

[Carles Capdevila Tejada]

Which you can make those “6–12 projects” do. All they need to do is go
the plugin manager, uninstall the old plugin from *Installed* (which
will prompt to restart—but do not), then select the new plugin from
*Available* and *Download now and install after restart* and agree to
restart to apply changes. When it comes back up, it should have only
the correctly-named plugin installed, and the existing organization
folders should be loaded without incident (assuming, again, you did
not change package names or anything).

Thank you, I renamed the packages back into their original name and it worked like a charm!

I thought that all that mattered there was the plugin name AKA artifactId.

 

From what I understand, the old plugin was never on any update
center—it is being newly hosted, under the new and correct name. 

That is correct. AFAIK it's not yet on the update center, I think I had to do 

some tinkering first for that to work.

Right now it's working with:

The good plugin name -> gitblit

The old package name -> com.tsystems.sbs.gitblitbranchsource

It seems to me that this is not perfect, but at least the plugin name is correct and this would 

work for our projects. Is the package name acceptable for you?

Many thanks Oleg and Jesse, your help is much appreciated :)

[Jesse Glick]

On Mon, Aug 27, 2018 at 10:02 AM Carles Capdevila Tejada
<capde...@gmail.com> wrote:
> Right now it's working with:
> The good plugin name -> gitblit
> The old package name -> com.tsystems.sbs.gitblitbranchsource
>
> It seems to me that this is not perfect, but at least the plugin name is correct and this would
> work for our projects. Is the package name acceptable for you?

Sounds OK to me. If you do decide to rename packages later, it is
possible, using `XStream.addAlias`.