Git plugin 5.0 require Jenkins 2.190.3

49 views
Skip to first unread message

Mark Waite

unread,
Mar 26, 2020, 9:43:45 AM3/26/20
to Jenkins Developers
The git plugin and git client plugin currently require Jenkins 2.138.4.  I chose that Jenkins version almost 18 months ago while working on the transition from JGit 4 to JGIt 5.

I think it is time to switch the minimum Jenkins version for the git plugin and the git client plugin.  I propose that the minimum Jenkins version for git plugin 5.0 and git client plugin 5.0 will be Jenkins 2.190.3.

We can still release versions of the git plugin and git client plugin for Jenkins releases older than 2.190.3 by basing those releases on earlier branches.

I frequently test the git plugin and git client plugin with the current Jenkins LTS line.  I sometimes test with the prior Jenkins LTS line.  Choosing 2.190.3 seems conservative enough to me and is much closer to what I'm actually testing than Jenkins 2.138.4.

Are there pitfalls or problems that I have not considered in making the Jenkins version required by git plugin 5.0 be Jenkins 2.190.3?

Fran and Bobby, what do you think of the idea?

Thanks,
Mark Waite

James Nord

unread,
Mar 26, 2020, 10:18:38 AM3/26/20
to Jenkins Developers
> Are there pitfalls or problems that I have not considered in making the Jenkins version required by git plugin 5.0 be Jenkins 2.190.3?

did you think of potential security issues and the need to to backport to the 4.x line so that older (commercially supported) LTS lines can upgrade?

Daniel Beck

unread,
Mar 26, 2020, 10:30:58 AM3/26/20
to Jenkins Developers


> On 26. Mar 2020, at 14:43, Mark Waite <mark.ea...@gmail.com> wrote:
>
> Are there pitfalls or problems that I have not considered in making the Jenkins version required by git plugin 5.0 be Jenkins 2.190.3?

2.190.x requires the BOM (-Duse-jenkins-bom) otherwise it won't compile out of the box. At least that's how I solved it for matrix-auth.

2.190.x seems like a solid choice at the moment, and also won't have implied dependencies as of today. But if the beta cycle is as long as it was for the previous major line, I'd recommend going with a more recent baseline; 2.138.x was a bad choice by the time Git Plugin 4.0.0 was finally released: obsolete for almost a year, two implied dependencies on newest releases, and its update center was retired just a month later.

Robert Sandell

unread,
Mar 26, 2020, 10:37:02 AM3/26/20
to Jenkins Developers
I think 2.204.x is the current favorite, but I don't think there is anything against 2.190 more than age.

/B

Mark Waite

unread,
Mar 26, 2020, 10:42:20 AM3/26/20
to jenkinsci-dev
On Thu, Mar 26, 2020 at 8:18 AM James Nord <james...@gmail.com> wrote:
> Are there pitfalls or problems that I have not considered in making the Jenkins version required by git plugin 5.0 be Jenkins 2.190.3?

did you think of potential security issues and the need to to backport to the 4.x line so that older (commercially supported) LTS lines can upgrade?


I think we've resolved that for older LTS lines by releasing security fixes simultaneously on multiple branches.  For example, SECURITY-1723 was released simultaneously in git plugin 4.2.1, git plugin 4.0.1, git plugin 3.12.2, and git plugin 3.10.0.1.  That was a lot of work, but it assured users of those specific plugin versions that they could increment from their current version to current version plus security fix.

That pattern can continue as needed.
 
--
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/e3a200be-8901-4071-8398-fb6baea987e4%40googlegroups.com.

Mark Waite

unread,
Mar 26, 2020, 10:47:58 AM3/26/20
to jenkinsci-dev


On Thu, Mar 26, 2020 at 8:30 AM Daniel Beck wrote:


> On 26. Mar 2020, at 14:43, Mark Waite wrote:
>
> Are there pitfalls or problems that I have not considered in making the Jenkins version required by git plugin 5.0 be Jenkins 2.190.3?

2.190.x requires the BOM (-Duse-jenkins-bom) otherwise it won't compile out of the box. At least that's how I solved it for matrix-auth.


If that is needed, I think that would be reasonable.  The git plugin and git client plugin are using the plugin bom to simplify their management of dependencies (for workflow tests among others).
 
2.190.x seems like a solid choice at the moment, and also won't have implied dependencies as of today. But if the beta cycle is as long as it was for the previous major line, I'd recommend going with a more recent baseline; 2.138.x was a bad choice by the time Git Plugin 4.0.0 was finally released: obsolete for almost a year, two implied dependencies on newest releases, and its update center was retired just a month later.


I don't intend to have an 18 month beta cycle ever again.  That was a bad experience for everyone.  

This beta cycle should be no more than 1-2 months because it does not require changes from other plugins like the git client plugin 3.x change required.  No breaking changes in API's in the transition from current git client plugin to git client plugin 5.0.  No breaking changes in API's in the transition from current git plugin to git plugin 5.0.
 
--
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.

Mark Waite

unread,
Mar 26, 2020, 10:57:31 AM3/26/20
to jenkinsci-dev
On Thu, Mar 26, 2020 at 8:37 AM Robert Sandell <rsan...@cloudbees.com> wrote:
I think 2.204.x is the current favorite, but I don't think there is anything against 2.190 more than age.


Thanks for that insight.  I hadn't reviewed the deployment statistics when I sent my proposal for 2.190.x.

Based on deployment statistics, it seems like 2.204 or 2.204.1 are a better choice than 2.190.3.  Stats show:
  • Almost 10x more installations of git client plugin on Jenkins 2.204.2 than any other single release (over 40 000 installations)
  • 53% of git client plugin installations are running 3.0.0 or newer
  • Almost 10x more installations of git plugin on Jenkins 2.204.2 than any other single release (over 40 000 installations)
  • 48% of git plugin installations are running 4.0.0 or newer
I interpret that to mean that half the users are "staying current" with at least Jenkins 2.204.  That half of users are also the most likely to update to git plugin 5.0 and git client plugin 5.0.

I think the proposal should be revised to base on Jenkins 2.204.1 with a 1-2 month beta period (instead of 18 months).

Are there significant negatives to choosing 2.204.1 instead of 2.190.3?

Mark Waite
 
--
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.

Francisco Javier Fernandez

unread,
Mar 26, 2020, 11:10:35 AM3/26/20
to Jenkins Developers
After seeing the stats, I'd go for the 2.204
To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

Jesse Glick

unread,
Mar 26, 2020, 5:17:19 PM3/26/20
to Jenkins Dev
On Thu, Mar 26, 2020 at 10:47 AM Mark Waite <mark.ea...@gmail.com> wrote:
> No breaking changes in API's in the transition from current git client plugin to git client plugin 5.0. No breaking changes in API's in the transition from current git plugin to git plugin 5.0.

So why bother bumping the major version to begin with?

Mark Waite

unread,
Mar 26, 2020, 5:29:22 PM3/26/20
to jenkinsci-dev
Good question.  I assumed (possibly incorrectly) that a change of required Jenkins version would best be handled by increasing the major number.  

Increasing the major number is also a chance to reduce the confusion caused when users mistakenly decide to use git plugin 3.x with git client plugin 3.x.

Is it a general practice that we can change the minimum Jenkins version without updating the major number?
 
--
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.

Tim Jacomb

unread,
Mar 26, 2020, 6:34:54 PM3/26/20
to jenkin...@googlegroups.com
You aren’t breaking anything so I don’t know why you would need to break it.

Jesse Glick

unread,
Mar 27, 2020, 4:18:56 PM3/27/20
to Jenkins Dev
On Thu, Mar 26, 2020 at 5:29 PM Mark Waite <mark.ea...@gmail.com> wrote:
> confusion caused when users mistakenly decide to use git plugin 3.x with git client plugin 3.x.

Are there incompatible changes in `git-client` that would mean you
cannot use an older `git`?

> Is it a general practice that we can change the minimum Jenkins version without updating the major number?

No.

Jesse Glick

unread,
Mar 27, 2020, 4:19:54 PM3/27/20
to Jenkins Dev
On Fri, Mar 27, 2020 at 4:18 PM Jesse Glick <jgl...@cloudbees.com> wrote:
>> Is it a general practice that we can change the minimum Jenkins version without updating the major number?
>
> No.

I mean, yes, you can. (“No” we do not generally update the major
version component of plugins just because `jenkins.version` has been
updated.)

Mark Waite

unread,
Mar 27, 2020, 4:38:25 PM3/27/20
to jenkinsci-dev
On Fri, Mar 27, 2020 at 2:19 PM Jesse Glick <jgl...@cloudbees.com> wrote:
On Thu, Mar 26, 2020 at 5:29 PM Mark Waite <mark.ea...@gmail.com> wrote:
> confusion caused when users mistakenly decide to use git plugin 3.x with git client plugin 3.x.

Are there incompatible changes in `git-client` that would mean you
cannot use an older `git`?


The transition from git client plugin 2.x to git client plugin 3.x included a breaking API change.  The breaking API change was due to the transition from JGit 4.x to JGit 5.x.   No incompatible changes have been made since git client plugin 3.0.0.

Git plugin 3.x depends on git client plugin 2.x and JGit 4.x.

Git plugin 4.x depends on git client plugin 3.x and JGit 5.x.

Other than the JGit API change, there were no other breaking changes in the transition from git client plugin 2.x to 3.x. 

There is at least one case where a user chose to upgrade the git client plugin to 3.x without upgrading the git plugin to 4.x.  I never tested git plugin 3.x with git client plugin 3.x and never intended that someone would choose that combination.  The combination appears to work, but it is not a combination I ever tested.

One excuse to change major number was to possibly reduce user confusion from version numbers.  However, I don't think that is enough justification, since typical sets of plugins have many different version numbers and users do not expect any correlation between one plugin version number and another.  The git plugin and git client plugin may be coupled in my mind but they are not necessarily coupled in the thinking of Jenkins administrators.

 
> Is it a general practice that we can change the minimum Jenkins version without updating the major number?

No.


That's good.  That means I can increment the minor version number instead, since the change of required Jenkins version is not justification to increment the major number.

I'll increment the minor number for the next release in any case, since there will be new functionality in the release.  It seems like that is enough in this case.  Changing the required Jenkins version is a much less significant change than I thought.

Thanks for the clarification!
 
--
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.
Reply all
Reply to author
Forward
0 new messages