Re: Jenkins 3.x

> We do not have a fresh new massive story to share. At the same time there could be a few changes to highlight: - Adoption of Configuration-as-Code as a recommended way to manage Jenkins. - Making emphasis on Jenkins-in-the-cloud applications and packaging, with making

Re: Hosting requests for similar projects

Since Jenkins already has a built-in extensible CLI, we could simply reject both `HOSTING` requests. For non-plugin repositories I see no compelling advantage to in-org hosting. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To

[Event]: cdCON CFP is open

Hi All, The Continuous Delivery Foundation is hosting its annual cdCON in June 23-24, 2021 and they are looking for talks on Jenkins, CI CD, etc. The (free) registration and CFP are open: - Early Bird Submission* Deadline: Friday, February

Re: Hosting requests for similar projects

I thought I replied to this a while ago. Apologies. I'm also not in favor of having two split projects. It's just confusing for end users and more likely to be abandoned with only a single maintainer. My vote is either arbitrarily pick one, or get them to decide which they want to use as the

Re: Has anyone implemented OpenTelemetry or similar observability APIs in Jenkins?

Hey, great to see you again, Cyrille! This sounds interesting. I'm still not a fan of their enormous dependency stack, but I'm sure it's sufficient for prototyping. :) On Tue, Jan 12, 2021 at 2:52 AM 'Cyrille Le Clerc' via Jenkins Developers wrote: > > Hello Matt, > > For Your Information > >

Re: Hosting requests for similar projects

Any other feedback for this? On Tue, Dec 22, 2020 at 12:01 PM Tim Jacomb wrote: > agree would be great if they could be merged > > and also the jenkins core (and winstone) CLI enhanced with a more modern > CLI library > > On Tue, 22 Dec 2020 at 18:13, Slide wrote: > >> Hi Everyone, >> >>

Re: Jenkins 3.x

The existing 1.x/2.x versioning scheme which only ever increases minor versions seems like it reinforces the idea that nothing is happening. Would going with a date-based versioning scheme help? For example YY.nn (year and release, roughly corresponding to week in year), or YY.m.nn (year,

Re: Jenkins 3.x

I would be 100% behind a change to Jenkins 3 if we do an actual major release. For example, I would just nuke the current navigation system. I think one major pain point is the lack of sane separation of global navigation, local navigation and contextual actions. Redoing the whole sidebar

Re: Jenkins 3.x

Marketing releases are indeed something we could consider. The next LTS baseline selection starts this week, with ETA in early April. This release will include a number of serious changes, and generally 3.0 might be justified from the technical point of view. At the same time, it IMHO requires

Re: Releasing JCasC support for ghprb-plugin

CCing the latest appointed maintainer. On 25/01/2021 18.55, Matt Sicker wrote: I'd argue that without a maintainer, a plugin would be better off archived until someone with sufficient interest to maintain it volunteers. We have plenty of plugins that are crucial to thousands of users with no