commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VOTE] Apache Commons-VFS2 2.1 rc0
Date Tue, 03 May 2016 17:17:35 GMT
On 3 May 2016 at 18:08, Josh Elser <elserj@apache.org> wrote:
> sebb wrote:
>>>
>>> >  Sebb -- would addressing these points in the release notes cause you
>>> > to
>>> >  change your -1 to a +1? I'd like to make all the changes I can ASAP
>>> > and roll
>>> >  the next RC. Because I haven't said it explicitly -- thanks for taking
>>> > the
>>> >  time to give all of the feedback that you have already.
>>
>>
>> I think we should drop sandbox from trunk entirely; that will resolve
>> the issues.
>
>
> I agree with you completely.
>
>> Ideally the duplicate archives should be dropped, but that is not a
>> blocker, just a nuisance when reviewing.
>
>
> Yeah, I'll try to figure out what's going on with that when I roll rc1. I'm
> not sure since it's not pulling directly from the apache.pom (I'm not sure
> what all the commons parent pom is doing yet).

It would be a lot easier if VFS were a single module project.
Maven does not handle multi-module projects well.
For example I just tried "mvn site" in the RC directory and it
complained about not finding various bits of VFS in the repo.
This does not happen with single module projects.

Once sandbox is removed, there's only core and examples; these could
be merged and the jars managed as NET does.
But that's maybe too much upheaval for now.

And sandbox could even be developed as a separate project (rather than
module) depending on VFS (which it does anyway).

>> I'm not yet convinced about the Clirr errors.
>> I tried running the previous tests jar against the current code.
>> There were some errors, but these may be due to code fixes. I've not
>> had time to investigate fully.
>> But in any case, the description in changes.xml needs to explain why
>> the Clirr errors are not a concern.
>
>
> IIRC, the errors that I saw were about new methods or fields which should be
> fine for binary compatibility (sans the aforementioned Tar* classes). Given
> what you said earlier and my personal understanding, this should not affect
> binary compat.
>
> I have it on my list to update the necessary docs with the "why" before rc1.
>
> LMK if/when you decide for certain about the API additions and whether or
> not they're OK. Thanks.
>
>
> ---------------------------------------------------------------------
> 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