It must be hosted in the jenkinsci org in order for it to be part of the
default plugin manager.
On Tue, Sep 12, 2017 at 1:26 PM Chenghao Shi wrote:
> Hi All, From https://wiki.jenkins.io/display/JENKINS/Hosting+Plugins I
> would like to confirm one thing that if a new
Hi All, From https://wiki.jenkins.io/display/JENKINS/Hosting+Plugins I
would like to confirm one thing that if a new plugin's source code must be
uploaded to github.com/jenkinsci or developers can choose to use their own
company's repo such as github.com/ ? Thanks!
--
You received this
Thanks for the information. So I'll stick to
the release:prepare release:perform mechanism.
Best regards,
Thomas
Am Donnerstag, 7. September 2017 14:08:59 UTC+2 schrieb slide:
>
> The versions built in the ci infra are SNAPSHOT versions and there is no
> tagging done for the release. The
There were several stability issues related to the core design of the
plugin. It didn't make for a good user experience.
In addition, Pipeline is now a core part of the user experience. It covers
the cases I needed when I originally created the Multi-Branch Project
Plugin. It has developer
Stephen, could you pay a visit to
https://github.com/witokondoria/branch-source-aged-refs-traits, to go on
with the traits work? Have finaly gone through the path of one repo per
trait, a module for each implementation (even there will be dummy releases
when adding a new implementation)
Some
Matthew, can you please elaborate on why did the plugin get deprecated?
I am not able to find any reasoning, just the deprecation release...
Thanks!
--
oliver
--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this
Mark, Thanks for the extensive testing. Despite the fact his was not
confirmed as remoting problem, I am leaving the remoting version bump
reverted so the version will be 3.10 in LTS 2.73.1 and the candidate
will be reconsidered for .2. So the current RC is what we will release
on Wednesday in