Re: Jenkins 3.x

Hi all, Just a quick update for this and the related discussions: - As we discussed at the governance meeting, the Jenkins 3 discussions were scheduled to the Jenkins Contributor Summit on June 25th . My plan

Re: Jenkins 3.x

On Wed, Jan 27, 2021 at 1:18 PM Tim Jacomb wrote: > > Date based > […] any thoughts on the effort involved here in release automation? > I think this would most easily be done by ditching `maven-release-plugin`. We have already done the tricky bits with `flatten-maven-plugin` etc. in JEP-305.

Re: Jenkins 3.x

n Monday, January 25, 2021 at 6:53:59 PM UTC+1 msi...@cloudbees.com >> wrote: >> >>> That's a good point. I still see people who don't know about pipelines >>> even though they've been around since Jenkins 2.0 IIRC. The updated UI >>> is also less well known. >

Re: Jenkins 3.x

; > > On Monday, January 25, 2021 at 6:53:59 PM UTC+1 msi...@cloudbees.com > wrote: > >> That's a good point. I still see people who don't know about pipelines >> even though they've been around since Jenkins 2.0 IIRC. The updated UI >> is also less well known. >&

Re: Jenkins 3.x

s > even though they've been around since Jenkins 2.0 IIRC. The updated UI > is also less well known. > > On Fri, Jan 22, 2021 at 9:23 PM Ming Tang wrote: > > > > I think the release of Jenkins 3.x is very urgent. Let me put forward > > another very important re

Re: Jenkins 3.x

> >> That's a good point. I still see people who don't know about pipelines >> even though they've been around since Jenkins 2.0 IIRC. The updated UI >> is also less well known. >> >> On Fri, Jan 22, 2021 at 9:23 PM Ming Tang wrote: >> > >> >

Re: Jenkins 3.x

still see people who don't know about pipelines > even though they've been around since Jenkins 2.0 IIRC. The updated UI > is also less well known. > > On Fri, Jan 22, 2021 at 9:23 PM Ming Tang wrote: > > > > I think the release of Jenkins 3.x is very urgent. Let me put for

Re: Jenkins 3.x

That's a good point. I still see people who don't know about pipelines even though they've been around since Jenkins 2.0 IIRC. The updated UI is also less well known. On Fri, Jan 22, 2021 at 9:23 PM Ming Tang wrote: > > I think the release of Jenkins 3.x is very urgent. Let me put f

Re: Jenkins 3.x

I think the release of Jenkins 3.x is very urgent. Let me put forward another very important reason: companies and users are abandoning Jenkins. Jenkins 2.x has a history of 5 years. In the past 5 years, Jenkins 2.x has many major features and incompatible modifications. The obsolescence

Re: Jenkins 3.x

Interesting, first I had seen Revapi. Would be worth checking whether it can replace japicmp in `jenkinsci/jenkins`, which I introduced as part of JEP-227 but had to patch in order to properly handle POM/classpath changes (and unfortunately that patch remains unevaluated). -- You received this

Re: Jenkins 3.x

Revapi is another great tool; we use it in Log4j2 nowadays after a couple releases accidentally introduced minor binary compatibility issues (but source compatible) in the logging API. On Tue, Dec 1, 2020 at 7:15 AM Ullrich Hafner wrote: > > > Am 30.11.2020 um 22:51 schrieb Matt Sicker : > > I

Re: Jenkins 3.x

> Am 30.11.2020 um 22:51 schrieb Matt Sicker : > > I think Jesse has articulated my own feelings fairly well here. I will > note that OSGi has some useful tooling [1] and semantics related to > semantic versioning, generic Java plugins/modules/components, and some > other well-explored areas

Re: Jenkins 3.x

I would also prefer some date based release numbering a la IntelliJ rather than semantic versioning, for all the reasons that Jesse has spelled out. On Mon, Nov 30, 2020 at 2:45 PM Jesse Glick wrote: > I do not think switching to a 3.x version number accomplishes much of > anything (even if we

Re: Jenkins 3.x

On Mon, Nov 30, 2020 at 4:52 PM Matt Sicker wrote: > tooling […] related to semantic versioning Note that we have, for example, https://ci.jenkins.io/job/Core/job/jenkins/job/master/API_20compatibility/ Interesting so far as it goes: will tell you whether _plugins_ updating to this version

Re: Jenkins 3.x

I think Jesse has articulated my own feelings fairly well here. I will note that OSGi has some useful tooling [1] and semantics related to semantic versioning, generic Java plugins/modules/components, and some other well-explored areas related to compatibility which our own plugin ClassLoader only

Re: Jenkins 3.x

I do not think switching to a 3.x version number accomplishes much of anything (even if we had done so several weeks ago, when the big changes were landing). I would much rather see Jenkins switch to either a date-based scheme, or just some opaque incrementing number like we have but without the

Re: Jenkins 3.x

My $0.02: Semantic Versioning is great for libraries; I'd certainly be in favour of migrating to it for plugins. For core, not entirely certain. In addition, you have PR labels that indicate when the changes require a major or minor version bump. Release drafter takes that into account (or

Re: Jenkins 3.x

Just keeping an eye on the thread it seems to me that, before any decision should be made about whether a bump to 3.x was done, a clear policy on versioning really needs to be introduced on what constitutes a major version bump so that it's clear that if xyz is implemented then that will be done

Re: Jenkins 3.x

There is clearly no consensus here, and IMHO we need to wait until the new Event officer takes the role. I doubt we can make a final decision by the next weekly release on Tuesday, so my suggestion is to keep discussing it and to also add it to the governance meeting agenda on Dec 02. On

Re: Jenkins 3.x

> On 27. Nov 2020, at 18:26, James Nord wrote: > > Could we maybe keep the discussion here to just a 3.x bump as we are more > likely to reach a consensus? As a technical/compatibility indicator, 3.0 makes little sense because it's late. None of the related documentation would even say

Re: Jenkins 3.x

> if we go for 3.x, should we also change the versioning scheme? Can this come later? I think any discussions regarding versioning schemes should go together with a proper deprecation & removal policy. We could use this chance, for example, to say "we're removing prototypejs in 2 years, by

Re: Jenkins 3.x

+1 for the 3.x as a statement of intentions to the end users and +1 for the time-based release versioning. On Friday, 27 November 2020 at 12:03:21 UTC fque...@cloudbees.com wrote: > I wouldn't object to bumping the version to a major (3.x). There are > enough changes, even if they are not

Re: Jenkins 3.x

I wouldn't object to bumping the version to a major (3.x). There are enough changes, even if they are not that impressive to average users. That said, I have some questions. - How could we do it? We cannot ignore the fact that we are 5 weeklies in after the changes have been merged. -

Re: Jenkins 3.x

> > I like the idea of the very clear dated releases. It makes support a lot > easier eg. "Oh your release was from november of last year, you should > upgrade" "okay, your using 2.65, when did that get released? oh 2 years ago?" > Like I never have to think when Ubuntu 20.04 came out, I know

Re: Jenkins 3.x

>> It's *my* very personal opinion, fwiw. >>>> >>>> -- Baptiste >>>> >>>> Le mer. 25 nov. 2020 à 17:37, James Nord a écrit : >>>> >>>>> Hi all, >>>>> >>>>> with the recent weeklies

Re: Jenkins 3.x

t; >>>> Whilst many open source plugins have been updated and made compatible >>>> with the old and new version by the people making the changes (and >>>> compatability layers have been added as far as possible), there can be >>>> closed source on

Re: Jenkins 3.x

rsion by the people making the changes (and >> compatability layers have been added as far as possible), there can be >> closed source ones that we have no sight of that can be broken. >> >> Given this is an API compatibility breakage, I am wondering why don't we >>

Re: Jenkins 3.x

> that we have no sight of that can be broken. > > Given this is an API compatibility breakage, I am wondering why don't we > bump the version number to Jenkins 3.x to signify the breaking API? > > Regards > > /James > > -- > You received this message because you are sub

Re: Jenkins 3.x

Hi all, I am also open to discuss the Jenkins 3.x release, as well as any changes in the versioning policy which would be helpful to Jenkins adopters. I am not a big fan of semver due to the same reasons as Daniel noted, but it is definitely one of the options on the table. My only ask here

Re: Jenkins 3.x

On Thu, Nov 26, 2020 at 1:53 PM Manuel Ramón León Jiménez < manuelramonleonjime...@gmail.com> wrote: > > Anyway, I would like, when the time comes, to introduce semantic > versioning , adding a > third number to the version and using them according

Re: Jenkins 3.x

gt;>>>> with the recent weeklies we have a couple of changes (Acegi >>>>> upgrade/table-to-div) that break compatibility in plugins. >>>>> >>>>> Whilst many open source plugins have been updated and made compatible >>>>> with the old and ne

Re: Jenkins 3.x

have been updated and made compatible with > the old and new version by the people making the changes (and compatability > layers have been added as far as possible), there can be closed source ones > that we have no sight of that can be broken. > > Given this is an API compatibi

Re: Jenkins 3.x

s is an API compatibility breakage, I am wondering why don't we >> bump the version number to Jenkins 3.x to signify the breaking API? >> >> Regards >> >> /James >> > -- > You received this message because you are subscribed to the Google Groups > &q

Re: Jenkins 3.x

iven this is an API compatibility breakage, I am wondering why don't we > bump the version number to Jenkins 3.x to signify the breaking API? > > Regards > > /James > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" gr

Jenkins 3.x

been added as far as possible), there can be closed source ones that we have no sight of that can be broken. Given this is an API compatibility breakage, I am wondering why don't we bump the version number to Jenkins 3.x to signify the breaking API? Regards /James -- You received this message