Hi, John, Thank you for your perspective. There are a few things in here that I wanted to respond, as the creator of Jenkins.
First, I totally understand the frustration you and Thomas, the original poster have. This feeling of fear of upgrade and breakage it might create is something we hear from many people. Your Jenkins is mission critical, and when an upgrade breaks Jenkins admins like you and Thomas would be under a lot of pressure to resolve it quickly. One breakage is one too many. Believe it or not, a lot of contributors deeply care about not making that happen. So the part of your message that tries to call them out is appreciated, and so is illustration of the pain it’s causing and why that’s important to you. Please keep those coming. However, an insult like “it’s a bunch of amateurs driving the bus” shouldn’t be a part of that message and it doesn't belong in this community. For one, at a practical level, it doesn’t help you move your cause forward, and if anything it distracts away from your core message. But perhaps more importantly to me, it also goes against the philosophy and the ethos of this project. This open-source community critically depends on volunteer contributors, and it is very important for me that this project be a welcoming, vibrant, and open community. Without everyone’s continued participation, and influx of new people, we simply won’t be able to solve the kind of challenges you are raising. This is so important to us that we even created code of conduct <https://jenkins.io/project/conduct/>. I saw that you put the “rant” marker to block the segment of your message that contained that phase, so I think you just slipped a bit too far in your frustration, in a moment of heat. And that happens to all of us. Now, I mentioned that a lot of contributors actually deeply care about not breaking people’s installations. I wanted to shed some light into what we are actually doing there. Changes to the core gets a great deal of scrutiny to explore the backward compatibility impact. Look at this one PR <https://github.com/jenkinsci/jenkins/pull/3380> that started yesterday and you’ll see discussion about fallback, backward compatibility, etc. Here’s another one <https://github.com/jenkinsci/jenkins/pull/2831> and I’ll throw in one more <https://github.com/jenkinsci/jenkins/pull/2759>. This is the norm and not the exception. >From time to time, we have no choice but to break backward compatibility. Many of those are security related, because those tend to be the kind of bugs that require a fix at the design level. But we do this very cautiously knowing the impact it can cause. JEP-200 is the most recent one, so let me explain how we approached this. First, we worked on a design document <https://github.com/jenkinsci/jep/tree/master/jep/200>, convincing ourselves collectively that this must be done and this is the best way to do it. Each code change was reviewed carefully <https://github.com/jenkinsci/jenkins/pulls?utf8=%E2%9C%93&q=is%3Apr+JEP-200>. There was a wiki page <https://wiki.jenkins.io/display/JENKINS/Plugins+affected+by+fix+for+JEP-200> used to track changes in plugins and to collaborate with plugin maintainers. Announcements are made <https://jenkins.io/blog/2018/01/13/jep-200/> to users & contributors calling out what this means and what steps to take, and yet another one <https://jenkins.io/blog/2018/03/15/jep-200-lts/> as the change landed to LTS. Slides <https://speakerdeck.com/player/f2b7e049ec46424b98ec4f0b58fd33bf#> and videos <https://youtu.be/Vfnc9t1RuYA> are created. This has been a <https://twitter.com/jenkinsci/status/973328720718045185> recurring <https://twitter.com/jenkinsci/status/974352667890855936> topic <https://twitter.com/jenkinsci/status/952297245910724608> on our official twitter account. Oleg and Jesse led a heroic effort to contain the impact as much as possible. And we are also not stopping there. The contributors of the project agrees that this requires a bigger measure. We want to move away from the need of assembling plugins and we want to offer something that just works and will keep working. Take a look at the goal and the mission of Jenkins Essentials <https://github.com/jenkinsci/jep/tree/master/jep/300>. One of the key motivations of this ongoing effort is to speak directly to the pain you raised. I invite you and others to join in those conversations in a constructive way. Hope that helps, On Mon, Apr 2, 2018 at 7:14 AM John Mellor <john.mel...@esentire.com> wrote: > On Fri, 2018-03-30 at 11:01 -0700, Thomas Dunlap wrote: > > I have inherited an AccuRev Jankins/Hudson CI. Jenkins version 1.472. > The previous developer stopped programming in 2012. I am trying to > determine the best way to upgrade the software. Since the development is > old I thought it would be best to see if I can get the 2 applications to > talk. > I have updated the licensing for Accurev and can access the CI development > platform through the AccurRev WebGUI. So half the problem is functioning. > > We are operating in the Windows OS environment. I tried to execute > Jenkins with no luck. > > I checked the Hudson services and the Event Viewer and have determined > that the service will not start. From the Services.cpl I start the Hudson > services and it immediately crashes. Whether run as a location system > account or an admin account. > > Can it be fixed by replacing the Hudson WAR file with the same version WAR > file. > > Any help would be appreciated. > > > I sympathize with you. I have one Jenkins instance in the same scenario, > stuck back at Jenkins 1.656 release. I cannot move it forward without > breaking 300+ mission-critical jobs. > > <rant mode=on/> > One of the most serious problems with Jenkins today is that API breakage > is routine, making it very difficult to even do minor upgrades without > breaking your builds. The root cause appears to be the team not checking > that a change works against all 2000+ plugins. Test cases are usually > inadequate or nonexistant, which does not help. Virtually every upgrade > breaks something unexpectedly. Backward compatibility seems to be a new > concept for some reason. E.g. the decision to change a blacklist into a > whitelist without fixing the 2000+ dependent plugins is clearly > irresponsible. Or git or gerrit or github breakage because someone does not > understand it. Or the repeated security "cleanups" that break selected > builds without fixup changes. IMHO, its a bunch of amateurs driving the bus. > > Another part of the problem is probably the language that Jenkins is > written in. Bugs per kloc is essentially fixed, independent of the > language, so it is clear that Java is not the correct choice, resulting in > far too much code to get the job done correctly. > <rant mode=off/> > > Realistically, in order to move up to current, you are going to have to > revisit every one of your workflows and redesign them as either the > underlying assumptions have been broken, or the API no longer works the > same way. Many will port forward easily, while others will need a complete > redesign. Keeping on top of updates is a full-time dedicated job here for > one person, which tells youjust how bad the issue is. If there was a > better-managed orchestration engine, we would have moved there a long time > ago in order to fix the complacency about the routine breakages. > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jenkinsci-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/1522678461.3049.113.camel%40esentire.com > <https://groups.google.com/d/msgid/jenkinsci-users/1522678461.3049.113.camel%40esentire.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAN4CQ4xYVMbVZ3Ey_ZJY6WSJYNHMaVfF4UOrUJyWH8jrWRmYOw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
