Submitted by rtyler on Thu, 2011-09-01 06:00
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
The testing of 1.409.2 has been spearheaded by community member
has created this fantastic test
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!
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.
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.
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 firstname.lastname@example.org mailing list, so join us!
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!
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.
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.