Hi
I suggest to test this on Windows as well. And do a fix in a single
file to ensure it works across the CI servers etc.
On Tue, Nov 20, 2012 at 11:08 AM, Babak Vahdat
wrote:
> Hi
>
> Looking at unit-tests all over the places we've got *tons* of this API
> call, like:
>
>assertTrue("File s
On Wed, Nov 21, 2012 at 2:25 AM, Hadrian Zbarcea wrote:
> Sounds good to me, not sure in what release it would make sense to make this
> change. One comment, there is no reason for lookupByNameAndType to not be
> called simply lookupByName (name override). The findByTypeWithName method
> name is a
Hi Hadrian,
I was *not* looking for any +1 but only wanted to *make sure* that there's
*no* good reason I'm missing here why there're *tons* of this call. So that
I though I should better ask other experienced riders before I start
removing (almost) all of those 226 calls!
~/dev/workspace/camel>f
Sounds good to me, not sure in what release it would make sense to make
this change. One comment, there is no reason for lookupByNameAndType to
not be called simply lookupByName (name override). The
findByTypeWithName method name is a bit ugly too, imho.
I'll think about it some more,
Hadrian
We did not try to release every 3 months after we started to issue patch
releases. I agree with Claus that what we have now is a better model,
and I prefer it as well.
That said, I agree the release cycle should be more predictable and
announced in advance. I like for instance the Ubuntu model
Unfortunately, it won't save any testing time as this is just a teeny,
tiny drop in the bucket, but it's a bit ugly.
Babak, you don't need a bunch of +1s, just go ahead and fix it :).
Thanks,
Hadrian
On 11/20/2012 08:07 PM, Willem jiang wrote:
+1 to remove that to save us some testing time :)
+1 to remove that to save us some testing time :)
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
(English)
http://jnn.javaeye.com (http://jn
IMO, there is no need for this additional API call.
+1 for removing it.
Best,
Christian
Sent from a mobile device
Am 20.11.2012 19:57 schrieb "Babak Vahdat" :
>
>
> Am 20.11.12 11:08 schrieb "Babak Vahdat" unter
> :
>
> >Hi
> >
> >Looking at unit-tests all over the places we've got *tons* of thi
Am 20.11.12 11:08 schrieb "Babak Vahdat" unter
:
>Hi
>
>Looking at unit-tests all over the places we've got *tons* of this API
>call, like:
>
> assertTrue("File should not have been deleted", new
>File("target/files/report.txt").getAbsoluteFile().exists());
>
>Which could simply be modified to
Hi
I think the current model is fine.
If you look at other projects they don't release minor releases more
quickly than we do.
Having the current scheduled with a patch release every 4-6 weeks is good.
Then bug fixes gets into a stable branch in timely manner, and allow
people to upgrade easily (
I really like the idea of having major releases more often. It makes transition
between releases faster and easier, even for users.
There was a talk few months ago about git usage in camel (instead of svn) few
months ago:
http://camel.465427.n5.nabble.com/DISCUSS-force-switching-from-SVN-to-GIT-
Hi
Looking at unit-tests all over the places we've got *tons* of this API
call, like:
assertTrue("File should not have been deleted", new
File("target/files/report.txt").getAbsoluteFile().exists());
Which could simply be modified to
assertTrue("File should not have been deleted", new
File
12 matches
Mail list logo
