Hi Oliver,
On 2011-12-02, wrote:
> Another attempt to fix the GUMP build using an ugly cast.
Seeing you jumping through these hoops I wonder whether it wouldn't be
better to look at the core issue. If configuration's compilation only
fails in Gump this means there is an API broken between the
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
Good day to you all:
I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am
not calling it RC3 because there are no changes in source files from the
last RC. The only difference is that I built from a fresh checkout of the
RC2 svn tag.
The changes from RC1 are what Sebb found:
On Fri, Dec 2, 2011 at 5:04 PM, Jörg Schaible 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 real
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-sanselan has an issue affecting its community integration.
This is
Just to bump your attention on the [RELEASE PROCESS] discussion that probably
could ensue at this point.
Best regards,
Henrib
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL-Jexl-2-1-tp4147180p4151203.html
Sent from the Commons - Dev mailing list archive at Nabble
To run the 2.0.1 tests against 2.1-SNAPSHOT, I have set up the branch
https://svn.apache.org/repos/asf/commons/proper/jexl/branches/COMMONS_JEXL_2_0_1_TEST
This is a copy ot the 2.0.1 tag, with minimal changes to the tests to
handle new features in the script engine, and minor error message text
c
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 c
It seems to me we have a hard time allowing both stability and usability.
Stability of APIs does not contradict usability of the library, at least
should not.
Some of us are looking for very long term/stable/high-quality solutions
because they need to aggregate lost of components, the stability u
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 expe
On Fri, Dec 2, 2011 at 4:38 PM, sebb wrote:
> On 2 December 2011 19:40, Gary Gregory wrote:
> > On Fri, Dec 2, 2011 at 1:19 PM, sebb wrote:
> >
> >> On 2 December 2011 17:52, Gary Gregory wrote:
> >> > +1. to release early, release often.
> >>
> >> But I hope we don't want to break user applic
On 2 December 2011 19:40, Gary Gregory wrote:
> On Fri, Dec 2, 2011 at 1:19 PM, sebb wrote:
>
>> On 2 December 2011 17:52, Gary Gregory 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
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 Tr
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, w
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" wrote:
> On Fri, Dec 2, 2011 at 1:19 PM, sebb wrote:
>
> > On 2 December 2011 17:52, Gary Gregory wrote:
> > > +1. to release early, releas
On Fri, Dec 2, 2011 at 1:19 PM, sebb wrote:
> On 2 December 2011 17:52, Gary Gregory 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 wit
On 2 December 2011 17:52, Gary Gregory 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?
We could always release major versions with package and Maven id
changes, and then compatibility issues would
Some of the release requirements are specific to Commons, not the ASF in
general.
-Adrian
On 12/2/2011 4:34 PM, Christian Grobmeier wrote:
On Fri, Dec 2, 2011 at 5:14 PM, henrib wrote:
Of course I am frustrated; I'm old enough to know it will pass...
More importantly, I now need to re-evalu
+1. to release early, release often. Go for v3, seems simplest. If someone
really wants fixes in 2.x, then you release from the branch.
Gary
On Fri, Dec 2, 2011 at 12:27 PM, henrib wrote:
> I've done the same thing and been pushing JEXL snapshots for sometime to
> avoid the unpleasant moment, s
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 p
On Fri, Dec 2, 2011 at 5:14 PM, henrib wrote:
> Of course I am frustrated; I'm old enough to know it will pass...
>
> More importantly, I now need to re-evaluate whether JEXL as an Apache
> Commons project is a library I can continue to use and recommend for
> professional usage; it has a shallow
I'll try to follow-up the discussion about the Clirr errors when it starts.
I hope you'll be able to serve as an RM.
Thanks for your answer,
Henrib
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL-Jexl-2-1-tp4147180p4147829.html
Sent from the Commons - Dev mailing
Of course I am frustrated; I'm old enough to know it will pass...
More importantly, I now need to re-evaluate whether JEXL as an Apache
Commons project is a library I can continue to use and recommend for
professional usage; it has a shallow community, only had one committer for
the past 3-4 years
On 2 December 2011 14:14, henrib wrote:
> Just a simple question to Sebb;
> Do you intend to pursue and release 2.1 or just leave it as is?
Yes, I would like 2.1 to be released.
Given that there appear to be some binary incompatibilies that cannot
be resolved without losing much recent work and
Henri,
On Fri, Dec 2, 2011 at 3:14 PM, henrib wrote:
> Just a simple question to Sebb;
> Do you intend to pursue and release 2.1 or just leave it as is?
This sounds somehow frustrated. Am I wrong?
Cheers
Christian
> Regards,
> Henrib
>
> --
> View this message in context:
> http://apache-comm
Just a simple question to Sebb;
Do you intend to pursue and release 2.1 or just leave it as is?
Regards,
Henrib
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL-Jexl-2-1-tp4147180p4147180.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---
>
> Change in binary layout means (unless your type implements
> readObject/writeObject methods, that has own rules) any change in the
> declaration of (inherited) members:
> - change of type
> - different declaration sequence (!)
> - change of transient mode
> or any change in the type inheritance
Hi Sébastian,
Sébastien Brisard wrote:
>>
>> Only if the binary layout has changed.
>>
>> - Jörg
>>
> Thanks Jörg for this answer. Only, could you be a bit more specific,
> please? I suppose that if I only change comments,or rename variables,
> I do not change the binary layout. In all other inst
28 matches
Mail list logo
