Core

Jenkins Long-Term Release 1.409.2 is out

We just posted the updated Long-term Release (LTS) of 1.409.2.

Just as a recap, with LTS releases, we plan on providing a release train that only has backported changes. 1.409.2 contains a handful of important bug fixes since 1.409.1. For more about LTS, see this wiki page.

Thanks to the heroic effort of those who are involved, namely Vojtech Juranek and a bunch of heroes, this release went through a rather rigorous testing, including all the automated tests we have plus a considerable number of manual eye-ball tests.

To download, click the "Long-Term Support Release" tab from the top page. If you've already been using LTS, you should start receiving update notifications soon.

Call for Testers: Upcoming LTS update

A couple of months ago Jenkins embarked on an new project, the Jenkins "LTS" (Long Term Support) release line. A LTS branch of development is common in most major open source projects, especially those with substantial corporate adoption, so this was a great step for the project as a whole.

We're now coming up on the second LTS release, which will be an incremental update to the previous one (1.409.1) with only the most important fixes back-ported to the branch.

Now is when we need your help.

We need testers and interested parties from the community to help verify the stability of the planned LTS update, 1.409.2, which is now in the release candidate stages.

The testing of 1.409.2 has been spearheaded by community member vjuranek who has created this fantastic test matrix to help coordinate testing of release candidates.

The LTS project is entirely community driven, so your input is invaluable in making these releases successful.

If you're interested in helping, speak up on the -dev mailing list and start pitching in on the test matrix!

JRuby Branch merged!

Yesterday, Kohsuke announced that the 'jruby' branch of jenkins-core had been merged to master.

This doesn't mean that we're done and that you can go forth and write pure ruby plugins... not by any stretch of the imagination. Instead, what it does mean, is that the Jenkins mainline is much more friendly to runtime analysis of classes with which it is not familiar.

The problem

When analyzing plugin classes, Jenkins uses just about every kind of metadata you can think of to get information about them: Class name, Field names, method names, member modifiers, annotations, you name it. It even uses the containing class relationship for inner classes to match Descriptors with what they describe.

It's all a great example of convention over configuration (CoC). In fact, I've never really seen CoC implemented in a Java project before as successfully as it has been in Jenkins. Plugin authors don't have to duplicate any metadata that Jenkins can figure out for you -- and it's alot! The drawback though, is that extensions depend very heavily on conforming to the structure of a conventional Java class.

The changes in this merge, and in several of the modules on which Jenkins depends, allow more than ever to get this information by asking an object directly rather than querying its private class structure.

The Kicker

Many of theses changes aren't even JRuby specific! While they do enable JRuby integration, They're really just making things more friendly for dynamic languages in general. So, in theory, it should pave the way for others like JavaScript and Python.

Where now?

We're still working on the ruby runtime and tools which will provide as crisp a Ruby development experience as we can. I don't want to proffer an estimate of when those will begin to be useable, but it is important to mark this very important milestone and explain what it does and does not mean.

We need you!

There is still much work to be done to enable a writing Jenkins plugins in Ruby, we are looking for people who know Ruby and feel like pitching in: writing Rake tasks, improving the glue layer, documentation, etc.

If you're interested, most of the action is happening on the jenkinsrb@googlegroups.com mailing list, so join us!


Ruby Plugins Hack Session Notes 6/23/2011

You know that the night is going to be productive whenever @kohsukekawa shows up, and last night was no exception. We talked about problems on the horizon, potential solutions, and then I spent the last half hour ripping a bit of code.

The truth of the matter is that most of the changes that have to be done to Jenkins core have already been made, so now the bulk of the heavy lifting falls to the Ruby side of things (right now, me).

Anyhow, on to the notes!

Attendees

@kohsukekawa, @cowboyd

extract more stuff into the jenkins-plugins.rb support library (@cowboyd)

We're in the process of extracting, normalizing, documenting all the goop that's currently residing in the ruby plugins playground into a formal plugin support gem called jenkins-plugins https://github.com/cowboyd/jenkins-plugins.rb

recruit Rubyists to implement non-Jenkins specific code (@kohsukekawa)

If you know Ruby and would like to be able to write Jenkins plugins with it, but don't know the first thing about Jenkins and/or JRuby, that's OK.

Jenkins Long-Term Support Release

We have released 1.409.1, our first long-term support (LTS) release, from the Jenkins project.

The idea of the LTS release is to provide a second release line the favors more stability and bug fix only maintenance. This release line branches off from a bit old Jenkins release (in this case 1.409), and we will only put important backported bug fixes. We'll keep releasing 1.409.2, 1.409.3, and so on, as such bugs appear, and in several months (our current thinking is 3 months) we'll designate another release and repeat this process all over again. I think it provides more comfortable upgrade path for larger deployments. For more about this, see Wiki.

In large companies that use Jenkins in a large scale, there often is a team of people who looks at incoming Jenkins release, tests it with their environments and their plugins, and then let their internal group consume them. With this release line, I'm calling for them to join the effort on this branch. Vojtech Juranek from Red Hat is already helping us tremendously, so is Yahoo in choosing the base release line and backporting. But it'd be great to get more people on board, as I think it'll benefit everyone to have a larger number of eyeballs on the same code.