Hallo Joerg! I understand your concerns about binary compatibility - just for the record, I eat our dogfood as well at work - anyway IMHO at the same time we should try to not put us in the position to stop the progression, I continue taking the [collections] as main sample: we now have a binary compatible code on /trunk, and the bigger part of our users switched to guava - that is a completely new API set; or [logging], that maintained binary compatibility, but today slf4j - yet another new API set - is used more often than our [logging].
Probably if we would have allowed more changes, we would have lost less users, but please take this tense strictly as a personal opinion. For my PoV - and please take in consideration that maybe I'm one of the youngest here, with less experience than you - too strict contraints, even if success stories like yours show the benefits, have their side effects as well - the worst of them is people left the development :( Al the best, Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Dec 2, 2011 at 11:04 PM, Jörg Schaible <joerg.schai...@gmx.de> wrote: > Simone Tripodi wrote: > >> Hi all guys, >> I would like to confirm Henri Yandell's concern about the cutting >> releases :( I honestly think we should speak less and practice more >> the "releas early and often" karma because the sad reality is... we've >> been not good on it :( >> My Maven community experience let me totally astonished, we have >> released the fluido-skin in ~160 commits and 1 RC, something that >> would not be possible here. > > [snip] > > Well, I see Fluido from a customer's view in the same category as Tomcat - > you do not release a component where other users build upon API-wise. Even > worse, our components are often used by other third party libraries that are > used to build applications. *Therefore* we take care. > > See, when I start a global build in our company the reactor contains over > 400 projects. I am quite sure that without dependency management I'd end up > with every single release of commons lang in my local repository that has > ever been made. The only reason why this works, is that all involved people > ever took care that the 1.x to 2.x was binary compatible for years (at least > for an upgrade). Now, we introduced lang3 and first components depend on it > - which is fine. But I realize that I might not get rid of lang 2.x probably > for the next couple of years. I am glad, that we have the possibility to use > lang3 with its up-to-date API, but I am also glad that I currently don't end > up with lang1, lang2, lang3, ... to lang9 ;-) > > [snip] > > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
