Jenkins 3.x

272 views
Skip to first unread message

James Nord

unread,
Nov 25, 2020, 11:37:21 AM11/25/20
to Jenkins Developers
Hi all,

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 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 compatibility breakage, I am wondering why don't we bump the version number to Jenkins 3.x  to signify the breaking API?

Regards

/James

Ivan Fernandez Calvo

unread,
Nov 26, 2020, 3:29:32 AM11/26/20
to Jenkins Developers
+1000 to considered those changes as a major change

Arnaud Héritier

unread,
Nov 26, 2020, 3:47:22 AM11/26/20
to Jenkins Developers
I think it's a good idea.
In the same spirit than 1.x -> 2.x (We justify the bump by the risk to impact a large number of plugins)



--
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/3929b9b0-d36b-4eb7-bc46-81fc01e7c21en%40googlegroups.com.


--
Arnaud Héritier
Twitter/Skype : aheritier

Ullrich Hafner

unread,
Nov 26, 2020, 6:56:08 AM11/26/20
to Jenkins Developers
Aren’t we are a little bit late for it, since these changes are already part of 2.x? Additionally, wouldn’t it be helpful if we have some groundbreaking user visible changes in 3.x as well (as we had in 2.x)? 

Manuel Ramón León Jiménez

unread,
Nov 26, 2020, 7:54:01 AM11/26/20
to jenkin...@googlegroups.com
Hi.

I don't have a strong opinion although I tend to think more like Ulrich. Maybe the UI revamp would be a good inflection point, in addition to these breaking changes..

Anyway, I would like, when the time comes, to introduce semantic versioning, adding a third number to the version and using them according to this way of versioning. In the future we can extend it to plugins and add some features in core to support / check / leverage this.

Thanks!

Olblak

unread,
Nov 26, 2020, 9:06:39 AM11/26/20
to Jenkins Developers ML
Aren’t we are a little bit late for it, since these changes are already part of 2.x? Additionally, wouldn’t it be helpful if we have some groundbreaking user visible changes in 3.x as well (as we had in 2.x)? 
I would say it's still fine as long as those changes aren't in the LTS


Anyway, I would like, when the time comes, to introduce semantic versioning, adding a third number to the version and using them according to this way of versioning. In the future we can extend it to plugins and add some features in core to support / check / leverage this.
Isn't it already the case for Lts releases?
Do we often have weekly releases that only contain bugfixes?

Daniel Beck

unread,
Nov 26, 2020, 9:53:06 AM11/26/20
to JenkinsCI Developers
On Thu, Nov 26, 2020 at 1:53 PM Manuel Ramón León Jiménez <manuelramon...@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 to this way of versioning. In the future we can extend it to plugins and add some features in core to support / check / leverage this.

We barely keep up with basic maintenance, and we're bound to get this wrong on a fairly regular basis given how we merge and release. Unless you're proposing to completely overhaul all of this, I'd say it's not worth the effort to then have people complaining whenever we mess up. 

Oleg Nenashev

unread,
Nov 26, 2020, 10:18:14 AM11/26/20
to Jenkins Developers
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 is to not hurry with the decisions. We will have a newly elected Release Officer on Dec 03, and I would wait until this happens before we do final decisions.

The next LTS cycle definitely looks to be a good opportunity for a 3.0 release from the technical standpoint. There is a lot of breaking changes that justify it. It would be great to deliver even more changes, but I doubt we will be able to have coordinated effort for that before the next LTS cycle (holidays and so on). So we can ship what we have.

On a separate note, Jenkins X 3.0 is also tentatively scheduled to early next year. It may lead to some confusion if Jenkins and Jenkins X releases happen within a short timeframe.

Best regards,
Oleg Nenshev

Baptiste Mathus

unread,
Nov 26, 2020, 11:44:58 AM11/26/20
to Jenkins Developers
TBH, I'd just embrace the more and more common yyyy-mm-dd ish pattern of releases.

It would kind of make this clearer to outsiders that the version numbers of Jenkins are close to nothing related to stability but more a very regularly recurring release pattern.

_Maybe_ I'd then agree with you for some new/adjusted version scheme *for LTSes*, but not worth doing this for weeklies IMO.

It's my very personal opinion, fwiw.

-- Baptiste

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

Beryl Snyder

unread,
Nov 26, 2020, 10:33:17 PM11/26/20
to jenkin...@googlegroups.com
Looking at this as someone who is more of a sysadmin(this is for the LTS releases),
I like semantic versioning because  I want to know when an upgrade will likely break things. 
It gives me an idea of how much time I need to burn stuff in/warnings to give and test before I promote from the testing environment.
That said, any pattern is workable, I would ask:
1) if you don't do semantic versioning don't make it look semantic 
2) any breaking changes are very clearly communicated (if i'm going to jump 2 or 3 releases i'm going to at most skim the release notes)     

Regards,
Beryl


Gavin Mogan

unread,
Nov 26, 2020, 10:55:44 PM11/26/20
to Jenkins Developers
I don't think anyone is arguing against the benefits of semantic versioning. Its really great for the reasons listed for the end user.
It is however, much harder to implement reliably in open source, when there's a lot of changes made by a lot of people. I know when I was involved with blue ocean, people got pissed at us when we released a change as a minor instead of major or patch or whatever. Something always breaks someones infra.

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 it was more or less april of this year. The tricky thing is how would dates work with LTS releases. It would be odd to have Jenkins 20201114-3 being released in early 2021.

I'm not sold on 3.x as major changes have already gone out, but i'm not against 3.0 either, and its nice for a marketing push but as oleg mentioned, it might clash with jenkins x.

So.. i guess i'm +/- 0 then?

Gavin



Raul Arabaolaza

unread,
Nov 27, 2020, 4:44:56 AM11/27/20
to Jenkins Developers
Hi all,

I believe it may make sense to use different versioning schemes for LTS and weekly?.

Semver and 3.x bump makes a lot of sense for LTS lines as the breaking changes may have been made public in the weekly but not in the LTS so we are still on time. Also LTS target audience, I guess, is much more worried about compatibility than weekly users so a semver versioning could help a lot.

About weekly I fully agree with the date based versioning

Regards  

jn...@cloudbees.com

unread,
Nov 27, 2020, 5:57:44 AM11/27/20
to Jenkins Developers
just to clarify as there are some points on this subject:

yes the breaking changes are already in a weekly release, but they are not in the upcoming LTS (2.263.1).

So yes I was proposing to change the version to 3.x before the new LTS.  People using the weeklies are probably[1] already a bit more used to breakage or fixing things, and working out what may need to happen (they are more used to Jenkins) than say the LTS users who are less so, and may not even be Jenkins users but managing Jenkins in the IT department for some users.

Hindsight about maybe bumping the versions as things where merged is a great thing, but that horse has bolted - so we are really only discussing something after the fact that would potentially help LTS users, or those that do not regularly update their weekly release. 

/James

[1] pure gut feeling, I have no data whatsoever to back this up

Ullrich Hafner

unread,
Nov 27, 2020, 6:26:49 AM11/27/20
to Jenkins Developers
>
> 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 it was more or less april of this year. The tricky thing is how would dates work with LTS releases. It would be odd to have Jenkins 20201114-3 being released in early 2021.
>

I think a scheme similar as used for IntelliJ would work as well for us, we can use weeks rather then milestones: year.week.patchlevel
I would not recommend to use the exact dates in the version as this is harder to correctly write in bug reports.

So 2020.30, 2020.31, and so on for the weekly releases, and 2020.30.1, 2020.30.2, and so on for LTS release.


fque...@cloudbees.com

unread,
Nov 27, 2020, 7:03:21 AM11/27/20
to Jenkins Developers
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.
  • 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 version X". That's why I think it may be a bit out of scope for this discussion (IMO).

Victor Martinez

unread,
Nov 27, 2020, 11:04:51 AM11/27/20
to Jenkins Developers
+1 for the 3.x as a statement of intentions to the end users and +1 for the time-based release versioning.

James Nord

unread,
Nov 27, 2020, 12:26:39 PM11/27/20
to jenkin...@googlegroups.com
>  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 version X". That's why I think it may be a bit out of scope for this discussion (IMO).

Could we maybe keep the discussion here to just a 3.x bump as we are more likely to reach a consensus?
we have tried and failed to get a deprecation policy for a long time - and I doubt we have enough time to do it before the next next LTS release

changing to a different version scheme using YYYY.WW would still be possible after the fact as 2020 is > 3  should there also be a consensus in a follow up. 


>  How could we do it? We cannot ignore the fact that we are 5 weeklies in after the changes have been merged.

we just change the version in the weekly and say Hey we are calling this 3.1 and we are a little late.  We do not have to be perfect

/James


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

Daniel Beck

unread,
Nov 27, 2020, 4:46:21 PM11/27/20
to jenkin...@googlegroups.com


> On 27. Nov 2020, at 18:26, James Nord <te...@teilo.net> 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 "from Jenkins 3.0" (if it did, it would be wrong). Plus there's no commitment to semver in the future, making this not even useful from an admin POV as an indicator that we're going to apply semver in the future. It might even be actively bad to create an expectation that incompatible changes bump the major version the next time we integrate a big change. People who read the documentation before updating will see huge warning signs either way, and can make an informed decision. People who don't will experience the same pain either way.

As a marketing/"there's big new stuff" indicator, I don't think there's enough big new stuff here from a regular user POV. Ideally XStream and Spring work without a ton of problems (and do we really want to highlight how bad things were until now?), and tables to div is nice but not on the scale I would expect as a user to justify the major version bump. All these changes are mostly internal, with some nice but overall modest visual updates to the configuration forms. Not to mention we'd need a solid plan for announcements, documentation, etc. -- a lot of that nature was done for Jenkins 2.

To me, this idea comes at least a month late, probably two, and going for it unprepared will just cause problems, while not actually accomplishing much.

Oleg Nenashev

unread,
Nov 27, 2020, 5:19:11 PM11/27/20
to Jenkins Developers
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.

Richard Bywater

unread,
Nov 27, 2020, 6:06:38 PM11/27/20
to Jenkins Developers ML
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 then we would need another version bump in the future. Otherwise we run the risk of having this discussion time and time again.

I think Jenkins 2.x made sense as it was quite a paradigm shift in the usage of Jenkins not (as far as I can tell or remember - happy to be corrected) anything to do with breakages or incompatibilities. It really announced that pipelines were the way of the future for Jenkins and therefore warranted a bump.

I'm not sure this change really has the same thing going for it as (again correct me if I'm wrong) we've had previous changes that have broken plugins to require them to be updated with fixes or changes before it could be upgraded?

Personally I dont think closed source plugins breaking with the change should be a major concern as long as we've clearly announced to plugin owners that in version xyz your plugin will need a change as they should really be keeping an eye on required changes as the majority I'd say are getting paid money by customers for the service.

Just my 2 cents :)

Richard

--
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 Van Holder

unread,
Nov 29, 2020, 8:49:47 AM11/29/20
to jenkin...@googlegroups.com
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 should).
So the actual version bump can be applied when cutting the release, to avoid issues where multiple PRs get merged and accidentally "overbump".

LTS releases are a bit of an issue in this regard. I'm not sure how they would be best handled.
I suppose you could have SemVer for weeklies, then tack on a 4th number for the LTSes (so if an LTS branch is cut from 4.2.7, the LTS is 4.2.7.1).
No longer SemVer then, but close enough (and my understanding is that LTS updates are for fixes only, not new API).

It does mean that LTSes may go from 4.2.7.3 to 8.1.0.1 if there has been especially active development in that quarter's weeklies.
I don't really see that as a problem, but some might.


Note: I have nothing against a YYYY.MM[.1] schema either; it doesn't communicate anything about the amount/impact of changes it includes, but that's what release and upgrade notes are for.


Jesse Glick

unread,
Nov 30, 2020, 4:45:39 PM11/30/20
to Jenkins Dev
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 meaningless `2.` prefix. Jenkins releases
break compatibility for someone, somehow, all the time; a number tells
you nothing about whether _you_ will be affected. We need to publish
clear, concise upgrade guides; encourage users to make backups or use
a config-as-code workflow; and of course try as hard as we can to not
break compatibility to begin with! In the case of JEP-227 & JEP-228
there have already been extensive plugin fixes released and few users
should actually be affected. Tables-to-divs has apparently caused more
regressions, but these should all be fixable long before the LTS.

In theory SemVer could be useful for libraries. In practice it seems
like a false promise to me. It is your tests which will tell you if an
upgrade is compatible, not some upstream maintainer’s fantasy.
Dependabot actually _keeps score_ and tells you whether a given update
broke CI for other people, which seems like far more valuable
information.

Matt Sicker

unread,
Nov 30, 2020, 4:52:16 PM11/30/20
to jenkin...@googlegroups.com
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 scratches the surface of.

[1]: https://bnd.bndtools.org/commands/baseline.html
https://bnd.bndtools.org/commands/diff.html
> --
> 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/CANfRfr0JZtW1x17eeUSVQzfAJgck08jVnfZ0%3DN4reZZ7RYx6fA%40mail.gmail.com.



--
Matt Sicker
Senior Software Engineer, CloudBees

Jesse Glick

unread,
Nov 30, 2020, 4:57:19 PM11/30/20
to Jenkins Dev
On Mon, Nov 30, 2020 at 4:52 PM Matt Sicker <msi...@cloudbees.com> 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 _might_ experience `LinkageError`’s (usually,
though not always, correlated to compilation errors).

Slide

unread,
Nov 30, 2020, 5:22:13 PM11/30/20
to jenkin...@googlegroups.com
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. 

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


--

Ullrich Hafner

unread,
Dec 1, 2020, 8:15:34 AM12/1/20
to Jenkins Developers
Am 30.11.2020 um 22:51 schrieb Matt Sicker <msi...@cloudbees.com>:

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 scratches the surface of.

[1]: https://bnd.bndtools.org/commands/baseline.html
https://bnd.bndtools.org/commands/diff.html


I’m using https://revapi.org/l in my plugins to detect incompatible API changes before a release. It seems to work quite similar and has support for Jenkins JPI files now. The included maven plugin warns me if I try to remove a method that actually might be used by a depending plugin. 

Matt Sicker

unread,
Dec 1, 2020, 11:05:55 AM12/1/20
to jenkin...@googlegroups.com
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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/96F88098-40ED-4002-869B-2842D5E26746%40gmail.com.

Jesse Glick

unread,
Dec 2, 2020, 1:02:20 PM12/2/20
to Jenkins Dev
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).

Ming Tang

unread,
Jan 22, 2021, 10:23:49 PM1/22/21
to Jenkins Developers
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, update, and requirements for higher versions of Jenkins core require constant upgrading of Jenkins and modification of the configuration. This is in the view of the end user (administrator) of Jenkins, but it is a toss in the view of the leader. Small versions usually mean small changes. For the leaders of Jenkins administrators, Jenkins 2.x is something that hasn't changed a lot for many years, but it requires labor-intensive maintenance and repeated exploration. The minor version upgrade hides the value of the new version of Jenkins! News organizations do not pay attention to minor version updates, and the leadership does not care about minor version updates. Only the Jenkins administrator knows what Jenkins has updated! Enterprises and users have begun to consider abandoning Jenkins! ! We need to let the outside know that Jenkins is undergoing major changes, not that it has not released a major version for 5 years.

Matt Sicker

unread,
Jan 25, 2021, 12:53:59 PM1/25/21
to jenkin...@googlegroups.com
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.
> --
> 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/9d0ad61c-e63e-47d5-9034-1b648e002198n%40googlegroups.com.

Oleg Nenashev

unread,
Jan 26, 2021, 6:25:58 AM1/26/21
to Jenkins Developers
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 a more fundamental change in Jenkins itself and its usage paradigm. For example, in Jenkins 2 we were mostly promoting Jenkins Pipeline and a few other related features, not the plugin unbundling as a breaking change. If the whole point is about marketing, we need to prepare well and to coordinate the rollout with CDF and key vendors so that we have a big marketing push.

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 Docker/Helm/etc. and downstream projects being promoted as first class citizens
  • Something else?
Anyway, I am not sure about taking the next LTS as 3.0. Tables to divs story is likely to be a problem for users due to regressions in various in-house and not popular plugins which have not been fixed yet. Thanks to Tim, Raihaan, Felix and many other contributors for the cleanup, but I doubt it will be as smooth as Jenkins 1->2 upgrade for the users. 

Best regards,
Oleg

P.S: If we do a major release, it would be awesome to get the terminology cleanup finished at least for the Jenkins core and major plugins. Taking our announcements this summer, this is not the topic we should roll over to Jenkins 3.

fque...@cloudbees.com

unread,
Jan 26, 2021, 6:41:06 AM1/26/21
to Jenkins Developers
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 would affect many plugins, but it's the sort of change I'd expect from a v3.

Daniel Beck

unread,
Jan 26, 2021, 7:19:02 AM1/26/21
to jenkin...@googlegroups.com
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, month, and release). The former would even work (mostly) with existing assumptions around version format being 2 parts for weeklies and an additional third part for LTS.

Alternatively, we can do what browsers are doing and just make every release a top-level release. Given how frequently release this may end up looking silly sooner rather than later though. Browsers aren't in the hundreds yet, we've done it twice already.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6b91c839-99ba-4dcc-af07-697265e03c03n%40googlegroups.com.

James Nord

unread,
Jan 26, 2021, 3:43:16 PM1/26/21
to jenkin...@googlegroups.com
> 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 Docker/Helm/etc. and downstream projects being promoted as first class citizens
  • Something else?

There is k8s bits that did not exist in the past now.  The cloud auto provisioning of agents, some community helm charts (and I think a k8s operator, but I have never used it as CloudBees has a different implementation).
There is soon (thanks to a PR) shotly going to be k8s secret support for both global and secret credentials (so mix C-asC and K8s in one)... (I should possibly do a blog post on that!)

/James

Tim Jacomb

unread,
Jan 27, 2021, 1:18:52 PM1/27/21
to Jenkins Developers, Olblak
Hello

Few points

> Marketing
Definitely value in considering this, a 3.x and a big marketing push could bring some good attention to Jenkins, but do we have enough big changes to justify, possibly if we consider not just this LTS but other changes since 2.x.

Some other stories worth highlighting: 
* GitHub checks integrations
* Plugin site new features, release notes, issues, and coming soon a report a bug link taking you to creating an issue for the plugin
* Read only Jenkins
*  UX modernisation
* Couple of pluggable storage stories made some progress: test results and fingerprints

> Date based
I support this, we'll never have a problem with hitting a .300 'minor version' if we do this. @Olblak  any thoughts on the effort involved here in release automation?

>  Number of breaking changes in weekly
I agree we could bump to 3.x to signal a higher upgrade risk, but agree with others that the changes aren't too 'flashy'.
I like Felix's idea of doing some bigger UX re-work for a 3.x, but I'm not sure we have enough contributors working in this area or time (assuming the next LTS), given that the next LTS selection is starting now.

Thanks
Tim

Jesse Glick

unread,
Jan 27, 2021, 2:09:46 PM1/27/21
to Jenkins Dev
On Wed, Jan 27, 2021 at 1:18 PM Tim Jacomb <timja...@gmail.com> 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. The JEP-229 system is the safest. You can also create a special variant like

mvn -Drevision=$(date -I) -Dchangelist= deploy

plus some profile activation for `maven-javadoc-plugin` & `maven-source-plugin` similar to what `produce-incrementals` does, plus manual tagging, with the downside that snapshot & incremental builds will not easily or safely compare properly to releases.

Oleg Nenashev

unread,
Jun 1, 2021, 11:57:16 AM6/1/21
to Jenkins Developers
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 was to have at least 3 hours of discussion of Jenkins 3 there, with focus on delivering changes needed for reducing maintenance overhead, Java 17 support, and Jenkins paradigm changes to reflect the modern CasC ecosystem and cloud environments.
  • I am sad to announce that I will be unable to drive this topic due to the conflict of interest I was unable to resolve.
  • If there is any contributor interested in driving the conversation for this topic, this is really good time to step up. I will be happy to help as a contributor summit organizer.
Thanks to all community members who contributed by providing feedback and reviews for some of my ideas in other channels.I might have some time to drive this effort in the future, but I cannot do it now.

Thanks for understanding,
Oleg Nenashev
Engineer, CloudBees

Reply all
Reply to author
Forward
0 new messages