|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 34
Messages: 34
Messages: 34
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
SpringSource Clarifies the Maintenance Policy
Rod Johnson gives a detailed account of the SpringSource policy update based on community feedback. From his blog: "Some have stated concerns that Spring would cease to be open source. The phrase "license change" kept being bandied around -- despite the fact that we were not changing the licenses of any Spring code. While such speculation was unfounded, it's still concerning."Let me take this opportunity once again to guarantee that Spring will remain open source for the community, under the current (Apache) license. Period. We are amending our maintenance policy in the light of community feedback. We will make regular binary releases from the Spring trunk available to the community, with no 3 month window. For each version of Spring, community releases will be available while it remains the trunk or until the next version is stable.
|
|
|
Message #270872
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thank you for listening, Rod
This is a step in the good direction. I think that, the same way that the old policy deserved our critics, this correction deserves our praise. Rod has been very patient listening to us, seeing our points, and thinking about the situation, and that certainly deserves our gratitude.
Errare humanum est. Now back to business!
Regards,
Daniel Fernández.
|
|
|
Message #270879
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thanks for Listening Rod
A couple of clients I was working for were seriously considering moving off Spring with the previous announcement. Now they will stay :)
|
|
|
Message #270888
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Thanks for Listening Rod
A couple of clients I was working for were seriously considering moving off Spring with the previous announcement. Now they will stay :)
+1
|
|
|
Message #270905
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Clarifies the Maintenance Policy
This changes completely the picture: no matter how much effort it takes to upgrade between two major versions, you'll always have a clear opensource upgrade map if you need it.
Works for me :)
Thankyou very much for listening to the community!
|
|
|
Message #270908
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Clarifies the Maintenance Policy
Rod : move appreciated.
What is NOT being said
======================
What are the chances that going forward, Springsource will adopt a 6-9 month policy for releasing major releases. Meaning, 5-6 months after a release(let's call that 3.0), a new major release(let's call that 3.1) will become stable enough and then the updates to the 3.0 version will STOP become publicly available ?
|
|
|
Message #270909
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Thank you for listening, Rod
Awesome move!!.
Rod is the Man!!, Congratulations to Spring Source developers.
Regards.
|
|
|
Message #270913
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Clarifies the Maintenance Policy
Meaning, 5-6 months after a release(let's call that 3.0), a new major release(let's call that 3.1) will become stable enough and then the updates to the 3.0 version will STOP become publicly available ?
In your example 3.0 minor releases will indeed no longer be available to the community but 3.1 releases will be available until 3.2 is released. The time period between major releases doesn't matter.
|
|
|
Message #270923
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Clarifies the Maintenance Policy
For my 2c, this is now a workable solution, and would seem like it will leave the community intact.
Rod, by 'binary releases', will the source be shipped also, to allow for debugging/tracing?
Ideally, the latest binaries + source could be put into http://repo1.maven.org/maven2/ for all Spring projects, e.g. spring core, webflow, etc.
|
|
|
Message #270934
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Clarifies the Maintenance Policy
Hi Greg,
The SpringSource Maintenance Policy FAQ has been updated and incorporates your questions.
Adam FitzGerald
SpringSource
|
|
|
Message #270940
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Clarifies the Maintenance Policy
Hi Greg,
The SpringSource Maintenance Policy FAQ has been updated and incorporates your questions.
Adam FitzGerald
SpringSource
Good news.
|
|
|
Message #270962
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Perfect
Rod,
Great move by SpringSource, I had not expected this at all. Thanks for listening to us. I think it takes a lot of guts to admit a mistake and correct it.
Thanks again.
|
|
|
Message #270967
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Clarifies the Maintenance Policy
Rod,
Thanks for listening to the community and showing that you are still willing to engage with Spring open source users in a constructive and positive way. I think that this will really reassure Spring users and be helpful not only for the Spring Framework but for all the many projects which use Spring as a platform for further efforts.
Well done.
Phil Zoio
http://impala.googlecode.com/ - Impala dynamic modules for Spring
|
|
|
Message #270968
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
1:0 for Open Source
This shows that SpringSource takes Open Source, especially the Open Source community very serious. I was shocked about the first license policy and I fell relieved about this update.
Mirko
:wq
|
|
|
Message #270979
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Clarifies the Maintenance Policy
Thanks for listening! The move is really appreciated. It also elevates the image of SpringSource team.
|
|
|
Message #270997
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No thanks to SS
sorry but i do not like at all all these "thanks".
imho what happened is:
1) first of all, SS tried to make money consciously "in the dishonest way";
2) after that, they realized that the spring users are not monkeys but people with brain.
That's why they decided to roll back from the "impolite way"; just because that decision would hurt SS, not because that decision would hurt the users.
Therefore I am not going to pronounce any "thanks" to SS for their roll back. The decision was taken just for thei personal interest
Of course i already sent bunches of thanks in the past adopting spring, spreading spring, developing projects based on springs, buying books, ... but that's another story.
For me, this is not the right moment to say thanks.
|
|
|
Message #271003
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No thanks to SS
>1) first of all, SS tried to make money consciously "in the dishonest way";
No, first of all Spring stated that they would discontinue providing official maintenance releases to old branches after they had reached a certain age, except to paying customers.
That's not about making money as much as it is about focusing your energy in the correct place. Spring continues to grow, and it gets ever more expensive and wasteful to backport bugfixes into older, more divergent codebases. For an open source java library, saying "sorry - use the latest major release" is hardly an uncommon position. Note that a lot of projects would have just stopped maintaining an older branch without warning - you wouldn't know it until you went 6 months without a maintenance release, at which point you'd be told to upgrade to the latest major version. Spring have made the (apparantly oh so shocking) step of announcing publicly what they are going to do before they do it, and you criticise them for what - profiteering? Get a grip.
> 2) after that, they realized that the spring users are not monkeys but people with brain.
No, after that they got badmouthed incessently by doomsayers who seemed to think (wrongly) they were making you pay to use Spring, or (wrongly) closing the source - or those who seek every opportunity to bash Spring for whatever reason.
Now, rather than time-box the end of maintenance to older releases, they have tied it to the release of a new version. So there will *always* be a current version of Spring that is getting maintenance patches. This is in response to the (accurate) criticism that if they stop maintaining one branch after 3 months, but it takes them another year to elease a major version, their user base will stagnate waiting for bugfixes.
What they have done is absolutely correct, and entirely sensible. The reaction here and elsewhere has been, frankly, appalling and unprofessional.
|
|
|
Message #271004
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No thanks to SS
No, first of all Spring stated that they would discontinue providing official maintenance releases to old branches after they had reached a certain age, except to paying customers....
False: Rod told that they would have not put tags for releases after 3 months in the public trunk.
Are you trying to convince me that putting tags in the svn for the community too is an expensive operation ?
Do you really think that it is easier to do it just on the private trunk instead of doing it on a unique trunk ?
Everybody can easily understand that this was simply a move (a very bad and unwise move indeed) to pull people toward the "paying" side.
I have nothing against the "paying" side: i am a redhat payer for example and "other stuff" payer but i do not want to be pulled on that side: it must be a decision of mine.
The reaction here and elsewhere has been, frankly, appalling and unprofessional.
I think it is clear to everybody where the unprofessional is.
|
|
|
Message #271005
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No thanks to SS
Paolo, I totally agree with your version of facts. I do not know where on Earth Dave Hewitt was, but things went exactly as you stated.
However I do not agree on the fact that they do not deserve a "thank you": at the end of the day, the software is theirs and they can do what they want; I again agree with you that the maintenance policy change was like placing a booby trap in the middle of the roads of Spring-based projects. That was, I again agree with you, a deliberate and intentional attempt at spilling money from the existing Spring user base using a rather questionable technique; now that this attempt completely backfired on them, they are forced to pull back.
In any case, besides my personal opinion on Spring (it is not so needed anymore), I will still stand clear from Spring, Springsource, and any other VC-funded-seemingly-open-source initiative awaiting their VC partners' new idea to spill money from their products.
Ciao.
|
|
|
Message #271008
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No thanks to SS
>1) first of all, SS tried to make money consciously "in the dishonest way";
No, first of all Spring stated that they would discontinue providing official maintenance releases to old branches after they had reached a certain age, except to paying customers.
That's not about making money as much as it is about focusing your energy in the correct place. Spring continues to grow, and it gets ever more expensive and wasteful to backport bugfixes into older, more divergent codebases. For an open source java library, saying "sorry - use the latest major release" is hardly an uncommon position. Note that a lot of projects would have just stopped maintaining an older branch without warning - you wouldn't know it until you went 6 months without a maintenance release, at which point you'd be told to upgrade to the latest major version. Spring have made the (apparantly oh so shocking) step of announcing publicly what they are going to do before they do it, and you criticise them for what - profiteering? Get a grip.
> 2) after that, they realized that the spring users are not monkeys but people with brain.
No, after that they got badmouthed incessently by doomsayers who seemed to think (wrongly) they were making you pay to use Spring, or (wrongly) closing the source - or those who seek every opportunity to bash Spring for whatever reason.
Now, rather than time-box the end of maintenance to older releases, they have tied it to the release of a new version. So there will *always* be a current version of Spring that is getting maintenance patches. This is in response to the (accurate) criticism that if they stop maintaining one branch after 3 months, but it takes them another year to elease a major version, their user base will stagnate waiting for bugfixes.
What they have done is absolutely correct, and entirely sensible. The reaction here and elsewhere has been, frankly, appalling and unprofessional.
+1 I thought the reaction to the first announcment was overblown. It was all about a delayed bug fix. No more. Take a look at GWT-EXT. They moved from LGPL to GPL and started charging. That's it.
Spring said "Paying customers get the bug fixes first after three months, but you'll get the fixes in the newest release(of which we drop frequently), so as long as you are willing to stay current, EVERTYHING IS FREE."
And that is worth that reaction? And now dozens of people who griped cannot even spare the two minutes to say "Thanks."
They even apparently went the extra mile to create extra price points of support for smaller shops.
|
|
|
Message #271011
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No thanks to SS
> False: Rod told that they would have not put tags for releases after 3 months in the public trunk.
And so what? If there are no official releases, why would there be tags? What *exactly* are you so worried about? No-one's demanding you pay for anything or breaking your code or closing any source or refusing to release any new versions at all.
> Everybody can easily understand that this was simply a move (a very bad and unwise move indeed) to pull people toward the "paying" side.
Completely untrue. It's a move to push as many people as possible onto the latest stable codebase, thus minimising the amount of effort spent maintaining legacy code - something they'd previously done for free but which has become increasingly untenable.
This is a *cost-cutting* measure, and a *focusing* of resource on the latest and greatest codebase.
Here is a challenge. Give me a list of open source java libraries which have maintainance releases for all of their major versions in parallel, in perpetuity. About the best I can think of off the top of my head is Tomcat, which maintains both 6 and 5.5. The vast majority of projects expect to be able to release a major version, and end of life the previous iteration at roughly the same time. Why is it okay for, say, ActiveMQ or Hibernate to do that, but not Spring?
The single genuine criticism was in arbitrarily time-limiting their maintenance offering rather than relating it to the actual release schedule. That's what this announcement addresses, a move which I think was inevitable.
|
|
|
Message #271013
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No thanks to SS
> Paolo, I totally agree with your version of facts. I do not know where on Earth Dave Hewitt was, but things went exactly as you stated.
I was right here, open mouthed at the sheer wrongness and self-righteousness of some of the comments that were made.
> I again agree with you that the maintenance policy change was like placing a booby trap in the middle of the roads of Spring-based projects.
How is it a booby trap if they continue to offer the latest version for free, and free access to the source of every single version as always? How are you forced to pay anything to anybody? Please explain the sense of entitlement you have that is somehow violated by Spring choosing to focus releases on a single major revision?
> a deliberate and intentional attempt at spilling money from the existing Spring user base using a rather questionable technique
Who has to pay and why? No hypotheticals - who *actually* has to pay extra *right now* and why?
> I will still stand clear from Spring, Springsource, and any other VC-funded-seemingly-open-source initiative awaiting their VC partners' new idea to spill money from their products.
So, you'll be steering clear of MySQL, ActiveMQ, Ubuntu - anyone that's come anywhere near any *evil* venture capitalists, right? And hey, why just the VC-funded ones? Surely the corporate backers are just as bad? After all - they've got lots of money and corporate interests to protect... Why not ditch everything from the Apache foundation - some of those people *get paid* for doing their work. Seeking to run a successful business off your hard work is inherently bad, right?
|
|
|
Message #271025
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No thanks to SS
No, first of all Spring stated that they would discontinue providing official maintenance releases to old branches after they had reached a certain age, except to paying customers....
False: Rod told that they would have not put tags for releases after 3 months in the public trunk.
Are you trying to convince me that putting tags in the svn for the community too is an expensive operation ?
Do you really think that it is easier to do it just on the private trunk instead of doing it on a unique trunk ?
Everybody can easily understand that this was simply a move (a very bad and unwise move indeed) to pull people toward the "paying" side.
I have nothing against the "paying" side: i am a redhat payer for example and "other stuff" payer but i do not want to be pulled on that side: it must be a decision of mine.
The reaction here and elsewhere has been, frankly, appalling and unprofessional.
I think it is clear to everybody where the unprofessional is.
+1
|
|
|
Message #271044
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No thanks to SS
Everybody can easily understand that this was simply a move (a very bad and unwise move indeed) to pull people toward the "paying" side.
It surely was a move to pull people towards the paying side, but it was by no means an "evil" move as you screaming complainers seemed to imply. The reaction on theserverside was hysterical and totally disproportionate.
And I won't even mention all of the comments by wannabe technologists that declare spring dead because they've found that other IOC containers exist.
The feeling one gets from all this story, is that Spring is not that appealing to the kids that need a new technology in order to get excited, and they try to bash it as it represents the "establishment": I guess something positive normally comes from this kind of revolutionary attitude on the long run, but as of now this has only been pointless whimpering.
I think it is clear to everybody where the unprofessional is.
Of course.
|
|
|
Message #271055
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No thanks to SS
Davide, your post cannot pass unnoticed.
move as you screaming complainers
Nobody ever screamed here. You will certainly notice that we - those rejected from your elite and highly intellectual establishment - were concerned about a move that would have introduced a lot of chaos in the "open edition" of Spring and a dangerous precedent for the open source community in general. TheServerSide is not the only website where people is complaining java.dzone.com is another. And, if you let me, why did Rod partially backed off from his initial policy? Just becase two, three whiners were "screamning" on TheServerSide? Or because he felt that the move could be countereffective?
And I won't even mention all of the comments by wannabe technologists that declare spring dead because they've found that other IOC containers exist.
Your Majesty and the Members of the Highly Intellectual Club(tm) of which you surely are one of the founding members forget to recall those who migrated from EJB to Spring because other ways of doing transactionality are now available; also those who moved from Struts to WebFlow, GWT, because "Strut sucks"; are they "wannabies" or simply smart people who move to the next best available technology? Aren't those wannabies (or masses, for you highly intellectual) those who decreeted Spring's success?
Oh sorry, Spring is not that appealing to the kids - perhaps you may want to disclose us your age before using this "highly intellectual jargon(tm)"?
|
|
|
Message #271062
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No thanks to SS
I avoided to answer you immediately because, before putting the fingers on the keyboard, i needed to take a veeery deep breath.
But when i got calm again, i already saw that Alessandro simply used the right words to supply the right answer to your Majesty.
cheers
Paolo the kid
|
|
|
Message #271071
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No thanks to SS
I was right here, open mouthed at the sheer wrongness and self-righteousness of some of the comments that were made.
Seriously, are you actually that surprised at the self-righteousness of some in the Java community over this? I certainly wasn't.
--
Bill Burke
JBoss, a division of Red hat
http://bill.burkecentral.com
|
|
|
Message #271084
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No thanks to SS
Seriously, are you actually that surprised at the self-righteousness of some in the Java community over this? I certainly wasn't.
So can you give us your version of things?
|
|
|
Message #271280
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Clarifies the Maintenance Policy
"until the next version is stable"
So I would assume that as soon as 3.1 is in BETA OR RC, they can call it stable ?
or is it only GA or RELEASE version only ?
thank you,
BR,
~A
|
|
|
Message #271310
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Clarifies the Maintenance Policy
Anjan
Your question is answered in the FAQ.
SpringSource will make regular source and binary releases of the current major version of Spring available to the community until the next major version is available (defined as a release candidate for that version).
Part of our point of the policy is to be able to focus our resources for the community (rather than for our customers) on the latest development, so we do not anticipate a long gap between an RC and GA release.
Rgds
Rod
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
