Hudson 2.0 has been released, bringing a new OSGi/Semantic Versioning scheme to the release numbers. Previously, Hudson was (and currently Jenkins is) released following the same versioning conventions as the JDK (specifically; the first version was always '1' and the next number incremented each release).
Going forward, Hudson releases will be versioned according to the discussion on the mailing list, which is also being used to test OSGi integration.
Although there have been a couple of Hudson releases since the fork (1.396 on 10th Feb and 1.398 on 14th March), this represents the first significant reset and forward looking plan. One of the significant changes is a modification to the Hudson plugin infrastructure, allowing JSR 330 for dependency injections to configure plugins.
Smoothie (or "hudson-inject") is an adapter on top of Sisu, a container built on JSR-330 injections, which allows the @hudson.Extension annotation to be replaced with a more generic @Named and @Inject annotations. This also allows components to be defined as @Singleton, which both ensures a single instance and avoids static lookups. Further, this option allows for non-singletons to be created, allowing a per-instance injection for services that need it.
OSGi compatibility is aided with Sisu, which is an extension of Google Guice (covered previously by InfoQ) to support dependency injection via OSGi. Note that Guice can be used in OSGi without Sisu; the 3.0 release provides standard OSGi interoperation out of the box. What Sisu does is to allow you to bind Guice injections with OSGi services without having to depend on an OSGi specific code. This allows a Guice component to run both inside and outside an OSGi container seamlessly. Sisu is the container used by Nexus as well as Maven 3.
JSR330 compatibility is also on the Jenkins roadmap; some parts have already been merged into Jenkins as well. This should permit the use of Smoothie within Jenkins if desired.
Finally, Hudson encourages Releasing Hudson Plugins into Maven Central via oss.sonatype.org, and documentation explains how to achieve this. Going forward, development of Hudson plugins will focus on the new JSR330 model, although for backward compatibility (and Jenkins interoperability) the non-JSR330 model will also be supported for some time to come. An appeal to those interested in the project is to vote on the bugs, in order to aid with prioritisation.