Request hosting for Serena Deployment Automation Deploy plugin

[PoisoN PoisoN]

Greetings,

I would like to host a new plugin for Serena Deployment Automation at Jenkins-ci. The plugin allows Jenkins job to be associated with SDA, automatically deploying any build artifacts through a configured DevOps process.

GitHub plugin name: sda-deploy-plugin
Personal GitHub ID: kabbyasov
GitHub repository: https://github.com/kabbyasov/sda-deploy-plugin

Thank you

[evernat]

Hi,

There is already a plugin for Serena:
https://wiki.jenkins-ci.org/display/JENKINS/Serena+Deploy+Plugin

This other plugin has a description which seems to be the same as yours and we can't see the difference:
"The plugin allows a Jenkins job to be associated with SRA, automatically deploying any build artifacts through a configured DevOps process."

Is your plugin different?
If yes, can it be merged with the existing plugin?

- Emeric

[PoisoN PoisoN]

Greetings.

Serena Deploy Plugin which you have mentioned is no longer supported from Serena and will be deprecated (and removed) soon. 

New plugin cannot be merged into old one, moreover it should be shown as separate plugin in plugin list so users could migrate to new plugin consciously.

суббота, 16 мая 2015 г., 13:55:19 UTC+3 пользователь evernat написал:

[Daniel Beck]

On 18.05.2015, at 10:49, PoisoN PoisoN <pois...@gmail.com> wrote:

> New plugin cannot be merged into old one

Isn't it the exact same code with a few classes and fields renamed and the package name changed? The POM is basically identical.

What's the difficulty in just declaring it version 2.0 or something, or e.g. removing some of the branding and calling it 'unofficial' if the vendor doesn't want to support it anymore?

[PoisoN PoisoN]

No, the plugin was rebranded to work with rebranded Serena product (which is now SDA - Serena Deploymen Automation). Also to avoid upgrade issues it should be separate plugin with new plugin id.

I work for Serena and I'm maintainer of both plugins. So, both plugins are official but old one is deprecated and will not be supported by Serena anymore. Once new plugin will be published old one can be deleted.

понедельник, 18 мая 2015 г., 21:04:29 UTC+3 пользователь Daniel Beck написал:

[domi]

I think this is irritating for the users…

Also you should include “serena” in the name of the new plugin, as SDA is not a well known acronym and users not familiar with serena should know by the name whether the plugin is interesting for them or not.

/Domi

--
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/a6caf8b6-d6f0-40d4-88ec-996a37868d96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PoisoN PoisoN]

Ok, the name can be shown as "Serena Deployment Automation Deploy plugin". Old name ("Serena Deploy plugin") is not suitable as Serena has many products and the plugin integrates only with one of them.

вторник, 19 мая 2015 г., 9:08:24 UTC+3 пользователь Dominik Bartholdi написал:

[PoisoN PoisoN]

Any chance to get this request resolved?

вторник, 19 мая 2015 г., 9:13:36 UTC+3 пользователь PoisoN PoisoN написал:

[Daniel Beck]

On 21.05.2015, at 10:03, PoisoN PoisoN <pois...@gmail.com> wrote:

> Any chance to get this request resolved?

It would help if you could explain the technical reasons that require this to be a new plugin, rather than e.g. a simple new plugin release. (And if we can get these issues resolved for the benefit of your users, all the better!)

So far, it only looks like you want to erase the old plugin name and establish the new one to match your renamed product:

> Old name ("Serena Deploy plugin") is not suitable as Serena has many products and the plugin integrates only with one of them.

It seems unnecessary to force users to configure things all over again when they want to get a new plugin version just because the service they're using has been renamed. Couldn't you just change the display name of the plugin? Note that when the new plugin isn't offered as update to the installed plugin via the update center, it may result in fewer users moving to your new release, keeping the old name around much longer.

Creating a new Git repo, losing all history, also seems like an excessive cut with the past of the plugin. The new plugin is clearly based on the old one.

> Also to avoid upgrade issues it should be separate plugin with new plugin id.

It is unclear what kind of issues these are. Did you refactor the plugin so the old configuration is incompatible and cannot be upgraded? If so, this should be reworked if possible:
https://wiki.jenkins-ci.org/display/JENKINS/Governance+Document#GovernanceDocument-Compatibilitymatters

If that's not possible, or if you don't want users to accidentally upgrade before certain preconditions are met, you can declare the new release incompatible with older ones, suggesting that users read the plugin changelog before upgrading:
https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions

If there are technical changes to the service that prevent the older version from working beyond a certain date, a minor update to the original release could add a note to Jenkins warning users of that change, followed by a '2.0' release that works with the reworked service.

Or maybe there is a reason for a user to run both plugins in parallel, because they use two different versions of your service in parallel?