Spring Maintenance Releases from the Community

Filed under: Java

A little bit of background: SpringSource recently announced that after the first three months after a major release they would only provide maintenance releases to paying customers. The press release was very unclear, but finally in the discussion at TSS Rod made clear what this means for non-paying customers:

  • SpringSource will create release builds within the first three months. Important: By “major release” they also mean releases like 2.5 or 3.1, which some might consider minor releases.
  • After the first three months SpringSource will commit all patches to the public Spring CVS repository, but will neither create release builds nor tag the releases (only to their paying customers).

I don’t want to judge whether SpringSource turned to the bad side by this. However, as Rod points out the real open source community would be able follow the source repository activity and compile a maintenance release themselves (Rod at TSS) when they need it for their project. But there is an issue, which Rod is is not addressing.

If every open source project will compile their own Spring releases and bundle them with their software, we are all very likely to get into BIG problems with our dependencies. If you use framework A and framework B in you project, which both rely on Spring, it is very likely they they will come with different builds of the Spring code, and now it is up to you to decide which Spring build to use in order to have running system. More so, all Maven dependency management efforts are in vain, when there is no tagged version. (BTW: This is not only an issue for non-paying Spring users, but also for the paying folks…)

So what can we do? I thought about this for a while, and I think there are not many options. Referring to daily builds from the repository will lead to proliferation and eventually to dependency hell. Some big companies may make the effort to build their own Spring releases and have some Spring mavens who are responsible for creating internal Spring releases. The third option, and IMO the best option are community builds.

The community can discuss the patches committed to the source repository and decide when to create a community release. This effort has already started: Clinton Begin registered freespring.org, which is supposed to provide tagging based on some voting system. That way, I hope we will all be able to continue to use Spring (and all the frameworks and other software, which build on it) as we do today.

Let’s support freespring.org and hope that SpringSource does care about their community and will not attempt to stop this effort!

Oct 5, 2008 at 20:22 | Permalink

2 Comments

  • 1. raveman  |  October 6th, 2008 at 2:30 pm

    I think because of action like this Spring will have no choice, but become close-source project(not that it matters). I see no problem for paying customers. maven can install artifacts from jar file and Spring doesnt change declaration of core classes between mayor releases. you can also override exclude jars in maven.

    Just buy Spring if you need it, dont be so cheap. people do pay for IntelliJ, Weblogic, WebSphere and Oracle.

  • 2. Stefan Kleineikenscheidt &hellip  |  October 12th, 2008 at 3:07 pm

    […] After a lot of feedback (including myself) from the community, SpringSource decided to tune their maintenance policy. Although we are not at the original status with the maintenance releases, I am satisfied that maintenance releases will be available for each major version until the next major version is out. […]

Leave a Comment

(Required, Why?)

(Required)

(Optional)

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed