In 2011 situation with Hudson and Jenkins was following(IMHO) - Hudson was a little bit stable, but development of Jenkins was a little bit faster.
What is the situation with "Hudson vs Jenkins" now in 2012?

- 16,295
- 33
- 103
- 133
-
2Good question. Let's see the differences. Hopefully, this won't stir up a flame war... – carlspring Jul 11 '12 at 13:31
-
1@carlspring We are using the very old version of Hudson in our team. It's time to update it. And I need to decide - should we update Hudson to the latest stable version or should we migrate to Jenkins. – Volodymyr Bezuglyy Jul 11 '12 at 13:47
-
4Frankly, if I were you, I'd invest some time in migrating it to Jenkins. We have some 300-400 jobs and migrating wasn't as smooth I'd hoped for, but it wasn't something I couldn't handle within a day. Perhaps the Jenkins guys have smoothened the migration process nowadays, but, nevertheless, it should not be too much of a hassle. – carlspring Jul 11 '12 at 13:59
-
224argh!!!Stop "closed as non-constructive" you fascists. I'm sick of finding questions I really want the most popular answer to like this one only to see they were closed. I've listened to your podcasts since the very first episode so I get what you're trying to do - but this is too heavy handed. At least move the question to the Programmers SE site and put a link here! – Rhubarb Apr 15 '13 at 10:07
-
23@Rhubarb Wish I could give you 100 upvotes for your comment! – Stefan Haberl Nov 13 '13 at 12:13
-
10I'm totally with you, Stefan and Rhubarb! – fazineroso Nov 15 '13 at 15:47
-
1You may not be able to alone, but society has. – Roger Mar 13 '14 at 19:07
-
8As there is still a growing interest in the answers to this topic (based on the number of views and upvotes for both answers), I would like to recommend a vote on re-opening it and changing the year to 2014. – carlspring Jul 23 '14 at 11:42
-
Hudson is dead these days, altho in general these types of questions belong in https://softwarerecs.stackexchange.com/ – Ben Creasy Feb 06 '18 at 16:11
3 Answers
I have used both Hudson and Jenkins. I have been following both change lists.
I still think we made the right choice by moving from Hudson to Jenkins. The Hudson core developers are now working on Jenkins. Those who are still employed by Oracle are the ones mainly supporting Hudson (as far as I am aware the Apache Maven people are contributing fixes as well).
I've filed a number of bugs back in the Hudson era. I can tell you most of them were resolved in Jenkins. Many months after their resolution, the Hudson people fixed or asked for further input on those particular bugs.
The majority of the plugin developers (almost all, that is) have migrated their plugins to Jenkins and now support Jenkins mainly. In terms of plugins Jenkins is developing much, much faster. There are now some paid plugins provided by Cloudbees.
As far as I am aware, the open source community has moved in it's majority to Jenkins.
Some companies who prefer to have paid support and don't want the hassle of migrating to Jenkins are still using Hudson. Frankly, I don't see why. Jenkins has commercial support too from Cloudbees, which is where Kohsuke Kawaguchi (the creator of Hudson) now works. Cloudbees now even have a free service for hosting GitHub hosted projects in their cloud. They let your OSS projects build for free! :)
Jenkins has improved it's support for the cloud. As mentioned above, Cloudbees also provide this SaaS in the cloud. I am not sure if and to what extent Hudson supports this. I think they're not so advanced at the moment; whatever the case, Hudson doesn't provide a SaaS for the cloud, as far as I am aware.
My opinion is that if you have to pick one, it should be Jenkins.

- 31,231
- 29
- 115
- 197
In terms of stability, for over a year Jenkins has offered a Long-Term Support (LTS) version for people who want to be more assured about the stability and support of the software they're installing.
Every three months or so, a previous release is selected which has been deemed as working well by the community of Jenkins users. This version is then branched, any important fixes (which have been "battle-tested") are backported into this Jenkins version, and then this release gets extra testing by various people and companies. Once it's ready for release, this becomes the new LTS version.
As new high-priority fixes come along, these are backported to the LTS version.
Numerous large users of Jenkins stick to the LTS line of releases, and according to the public Jenkins usage statistics, several thousand deployments are using it.
This should mean the LTS version you are downloading is even more stable than a random version chosen from the usual weekly release line.
Beyond the statistics, the situation regarding Jenkins usage, community size, its level of development, rate of new features added, number of new plugins and mailing list activity in comparison to Hudson doesn't seem to have changed (i.e. Jenkins remains ever-further ahead).
Basically, most of the points made in this previous discussion still apply, though the initial corporate support of Hudson appears to have subsided a little.

- 1
- 1

- 110,418
- 27
- 198
- 193
I think https://stackoverflow.com/a/5970813/556520 answers a lot of important questions about the hudson vs jenkins issue. The topic explains both sides of the situation with pros and cons for each product.
From personal experience working with CI for years, and recently started developing for Hudson, I would stick with the stable version of hudson just because jenkins is doing more development and support for their cloudbees service, where hudson has moved to the eclipse foundation and is not developing for a service. That's just my $0.02.
-
3Yes, thank you. But those answers is for 201--2011. The situation could change in 2012. – Volodymyr Bezuglyy Jul 12 '12 at 07:08
-
1Cloudbees and Jenkins are separate and independent entities. Why not stick with Jenkins which, as you mention, has more features, but go for the stable LTS release? – Christopher Orr Jul 28 '12 at 20:51
-
As long as cloudbees developments are good from the product, I don't undertand what could be the issue there. With Oracle involved, there was clearly an issue as Oracle where more concerned about their profit and less about the product roadmap. – JAR.JAR.beans Nov 25 '12 at 20:47