Hudson 2.0がリリースされ、新しいOSGi/セマンティックなバージョニングスキームでリリースナンバーがつくようになった。これまでHudsonは（そして現在Jenkinsは）JDKと同じバージョニング規約に従ってリリースされていた（具体的には、最初の番号は常に1、次の番号がリリース毎に増加していた）。
将来的には、Hudsonのリリースはメーリングリストでの議論に従ってバージョニングされることになるだろう。この方法は現在OSGiとの統合のテストにも使われている。
Hudsonはそのフォーク以来、2度のリリースが行われたが（2月10日に行われた1.396と3月14日に行われた1.398）、今回は初めての重要な仕切り直しと前進のための計画を表したものだ。大きな変更の1つはHudsonプラグインのインフラストラクチャの修正であり、それにより依存性注入に対するJSR 330によってプラグイン設定が可能になっている。
Smoothie （または、"hudson-inject"）は、JSR-330インジェクションをもとに構築されたコンテナSisu上のアダプタであり、それにより@hudson.Extensionアノテーションをより一般的な@Namedや@Injectアノテーションに置き換えることができる。 また、これによって、コンポーネントを@Singletonとして定義することが可能になっており、単一のインスタンスであることを保証しstatic検索を回避している。さらに、このオプションにより非シングルトンも生成可能であり、サービスに対するインスタンス単位のインジェクションが可能になっている。
OSGi互換性はOSGiを通じて依存性注入をサポートするための（InfoQで以前紹介した）Google Guice拡張であるSisuによって支援されている。ここで注意すべきはSisuなしでもGuiceはOSGi内で利用可能であることである。3.0リリースで、特に設定などを必要としない標準的なOSGi相互運用の機能を提供している。Sisuが実現していることはGuiceのインジェクションをOSGi特有のコードに依存する必要なくOSGiサービスと結合することができるようにすることである。このことにより、GuiceコンポーネントはOSGiコンテナの内側でも外側でもシームレスに実行できる。SisuはNexusだけでなくMaven 3でも使われているコンテナである。
JSR330互換性はJenkinsロードマップにも載っている。Jenkinsにすでにマージされている部分もある。これにより、必要ならJenkins内でSmoothieの利用が可能になるはずである。
最後に、Hudsonはoss.sonatype.orgを通じてMaven CentralにHudsonプラグインをリリースすることを後押ししていて、ドキュメントではこれをどのように実現するかを説明している。将来的にはHudsonプラグインの開発は新しいJSR330モデルにフォーカスすることになるだろう。非JSR330モデルも後方互換性のため（そして、Jenkinsとの相互運用性のため）にいつかはサポートされるであろうが。プロジェクトに興味を持つ人々へのアピールは、優先順位をつけてもらうためにバグに対する投票をすることで行うことになっている。