commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [JEXL] Jexl 2.1?
Date Fri, 02 Dec 2011 23:58:00 GMT
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.schaible@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message