commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <grobme...@gmail.com>
Subject Re: [JEXL] Jexl 2.1?
Date Fri, 02 Dec 2011 20:59:03 GMT
Gentlemen,

big +1 from me too to speed up and stop the slavery of the 100 mad
"fix me" rules. I will gladly vote +1 to releases which pass the unit
tests but do not fulfill the maven reports (as long as I can't see
really nasty bugs).

Cheers,
Christian



On Fri, Dec 2, 2011 at 9:45 PM, Simone Tripodi <simonetripodi@apache.org> 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. Of course we have issues there, but the
> pragmatism and the agility are totally surprising, that's why they
> have so many components/plugins/shared modules etc etc
> OTOH here at commons we have commons-collections, or
> commons-catastrophe like someone called in his blog: I recently
> proposed a short-therm roadmap, the big mountain that appeared in
> front of me simple made me feel to went away - it would have required
> a year of work - in the meantime Google-Guava continues publishing
> releases and we've lost users that migrated to more maintained
> FWs.We've had the Generics enabled in collections for a long time -
> even before that I joined as Sandbox contributor - but we've never
> released because of, as Christian already explained, endless
> discussions that induce people to give up.
> I think we suffer the "fix X before release" and "follow the roadmap"
> syndrome and we should add a little more of dynamism to improve.
> oh, and btw: big +1 to Gary and James :)
>
> Just my 0.00002 cents, yours,Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Fri, Dec 2, 2011 at 9:08 PM, James Carman <james@carmanconsulting.com> wrote:
>> Also remember that releases can't be vetoed.  Majority wins and must have 3
>> +1s.  You'll have mine on a 3.x release!
>> On Dec 2, 2011 2:40 PM, "Gary Gregory" <garydgregory@gmail.com> wrote:
>>
>>> On Fri, Dec 2, 2011 at 1:19 PM, sebb <sebbaz@gmail.com> wrote:
>>>
>>> > On 2 December 2011 17:52, Gary Gregory <garydgregory@gmail.com> wrote:
>>> > > +1. to release early, release often.
>>> >
>>> > But I hope we don't want to break user applications.
>>> >
>>> > > Go for v3, seems simplest.
>>> >
>>> > Simpler for whom?
>>> >
>>>
>>> Simpler for people to use the latest version with new features. Users have
>>> to make a conscious decision to upgrade to a new release, there is no
>>> coercion. A new release, in 2.x or 3.x carries different migration costs.
>>> If the new features of a 3.x matter to me, I accept the costs. If the
>>> releasing a new feature is incompatible in 2.x, I have to deal getting it
>>> in a 3.x with package name changes (and any other breakage.)
>>>
>>> Gary
>>>
>>>
>>> >
>>> > We could always release major versions with package and Maven id
>>> > changes, and then compatibility issues would be irrelevant.
>>> >
>>> > However, would most end users want that?
>>> > (JDBC versions, anyone?)
>>> >
>>> > Assuming that there are many more users of the code than there are
>>> > developers, then I think the developers owe it to the users not to
>>> > break things unnecessarily.
>>> > Particularly for projects such as Commons, which are generally only a
>>> > small part of a larger application.
>>> > Projects like Tomcat or JMeter which are largely self-contained can
>>> > afford to make many more internal changes, but they still need to
>>> > ensure upwards compatibility as far as possible.
>>> >
>>> > > If someone really wants fixes in 2.x, then you release from the branch.
>>> >
>>> > The reason I started on this was to see if we could tweak the code
>>> > sufficiently to avoid having to do a major version release.
>>> > I think we are nearly there.
>>> >
>>> > So yes, more work for the developers, but a lot less hassle for most end
>>> > users.
>>> >
>>> > > Gary
>>> > >
>>> > > On Fri, Dec 2, 2011 at 12:27 PM, henrib <henrib@apache.org> wrote:
>>> > >
>>> > >> I've done the same thing and been pushing JEXL snapshots for sometime
>>> to
>>> > >> avoid the unpleasant moment, so unpleasant that I've procrastinated
>>> > enough
>>> > >> to now have to consider alternatives.
>>> > >> I find disturbing that committers fear to release and that goodwill
to
>>> > >> share
>>> > >> features and code is killed by the process that should help publish
>>> > them -
>>> > >> not oppose them!
>>> > >>
>>> > >> I agree that a "release early, release often" scheme would help
but
>>> > I've no
>>> > >> idea how to achieve this without a "release faster" mean.
>>> > >>
>>> > >> However, I ultimately suspect that the vested interest of some
in
>>> > promoting
>>> > >> a hard, difficult and lengthy process relates to how their bills
get
>>> > payed
>>> > >> and by whom; there is a huge difference in those of us doing this
as a
>>> > >> "goodwill hobby" - so to speak - because we feel it is good ethics
to
>>> > >> contribute back and those who make a living from it. Can't blame
them
>>> > for
>>> > >> making sure their fees stay high by ensuring "hobbyists" don't
get too
>>> > >> efficient! (just kidding :-))
>>> > >>
>>> > >> Cheers,
>>> > >> Henrib
>>> > >>
>>> > >> --
>>> > >> View this message in context:
>>> > >>
>>> >
>>> http://apache-commons.680414.n4.nabble.com/JEXL-Jexl-2-1-tp4147180p4148135.html
>>> > >> Sent from the Commons - Dev mailing list archive at Nabble.com.
>>> > >>
>>> > >> ---------------------------------------------------------------------
>>> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> > >> For additional commands, e-mail: dev-help@commons.apache.org
>>> > >>
>>> > >>
>>> > >
>>> > >
>>> > > --
>>> > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> > > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>>> > > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>> > > Blog: http://garygregory.wordpress.com
>>> > > Home: http://garygregory.com/
>>> > > Tweet! http://twitter.com/GaryGregory
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> > For additional commands, e-mail: dev-help@commons.apache.org
>>> >
>>> >
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

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


Mime
View raw message