On Fri, Aug 1, 2014 at 9:35 AM, Mark Waite <[email protected]> wrote:
> You've adapted the git plugin to the newer SCM API
> on the master branch, and have offered it as a 2.3 beta pre-release.
Right. By marking it 2.3-beta-1 I ensured that it only appears on the
experimental update center, which is useful for people running
pre-1.568 weeklies.
> I don't understand how to use the LTS update center, and how to push a
> plugin release to the LTS update center separately from the standard update
> center.
There is nothing special you need do. Just perform a plugin release
whose baseline version is compatible with the current LTS. In this
case, publishing releases from the 2.2.x branch does that. (Simply git
checkout 2.2.x && mvn -B release:{prepare,perform} works as expected.)
> Doesn't that also mean that once 2.3 is released, Jenkins versions prior to
> the release of that new API won't be able to use the git plugin?
Well, they will not be able to use 2.3+. They will be able to use
2.2.x (assuming 1.509+ of course). The question is which UC you are
using. If you are using an LTS build of Jenkins, you are by default
using the LTS UC, so only 2.2.x would be offered even if 2.3
(non-beta) were released.
The problem would only be for people running weekly (non-LTS) releases
predating 1.568; they would see 2.3 on their UC but not be able to use
it. (Currently the Jenkins plugin manager allows you to install a
plugin marked incompatible; I intend to fix that so the option would
not even be selectable.) This is not ideal, but one would hope that
most people who are using weeklies are in fact using relatively recent
weeklies anyway, and this one is already six weeks old.
Ideally the Jenkins update center would dynamically serve just those
plugins compatible with your current core, whatever that is. (Jenkins
sends its version in a query parameter when requesting content, so
this could be accomplished purely on the server side.) There is also a
related RFE open for the UC format to allow multiple versions of a
plugin to be offered, so that the newest compatible one could be
offered. Either improvement would allow plugins to be freely released
with whatever core dep made sense at any given time.
By the way CloudBees operates its own set of update centers, using an
unrelated infrastructure to the Jenkins OSS one, which includes all
the OSS plugins plus the CloudBees proprietary ones. Currently this
also does not automatically select plugins compatible with an
arbitrary core version; but it does make it fairly easy (GUI
configuration screen) to create multiple UCs based on a match of the
core version, so we set up distinct UCs for each historical LTS line
(up to one year old), plus one for weeklies and one for experimental
plugin releases.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
