Also, looks like I'm wrong about the static member moving up to a parent
class (WebdavFileProvider to HttpFileProvider). I thought this wouldn't
work, but a quick experiment shows that it's fine.
Josh Elser wrote:
https://issues.apache.org/jira/browse/VFS-377 is the biggest
not-easily-fixed ch
https://issues.apache.org/jira/browse/VFS-377 is the biggest
not-easily-fixed change that breaks binary compatibility for 2.1 against
2.0. The bzip/gzip file object changes are easily restored, as is a
moved static member (I don't believe this is something that would
I can commit these changes
Has anyone looked at whether the changes really do affect BC?
Note that the Maven Clirr does not distinguish between source compat and BC.
Breaking source compat is not as serious an issue.
For example, the new methds in various interfaces don't affect BC:
https://docs.oracle.com/javase/specs/jls
: [VFS] 2.1 clirr report
Hah, thanks for the details, Ralph. I will be sure to bring myself up to
speed.
That being said: I would still like to get some consensus from those who
will be voting from the PMC on what should be done, given the current
report (since my opinion and thus vote are non
So, just call 2.1 instead 3.0? Fine by me.
Package name becomes o.a.c.vfs3? ArtifactId becomes (variants of)
commons-vfs3? Please confirm, Gary.
I don't think we need to expound any more about why compatibility is
important. No one has even presented any such argument. Let's stick to
action
Let's look at this from a different POV:
1) If we release 2.1 as is, we are creating a risk. We are strictly
speaking breaking BC.
2) If we release trunk as 3.0 with a package and Maven coordinate change,
then there is zero risk. If you want to use the new version, you MUST
change your imports.
T
Hah, thanks for the details, Ralph. I will be sure to bring myself up to
speed.
That being said: I would still like to get some consensus from those who
will be voting from the PMC on what should be done, given the current
report (since my opinion and thus vote are non-binding :D)
http://hom
FWIW, these discussions are not new. You might enjoy reading these threads -
http://www.mail-archive.com/user@commons.apache.org/msg03711.html. But maybe
not! ;-)
Ralph
> On Apr 29, 2016, at 12:43 PM, Ralph Goers wrote:
>
>>
>> On Apr 29, 2016, at 10:57 AM, Josh Elser wrote:
>>
>>
>>
>
> On Apr 29, 2016, at 10:57 AM, Josh Elser wrote:
>
>
>
> Ralph Goers wrote:
>>> On Apr 29, 2016, at 9:27 AM, Josh Elser wrote:
>>>
>>> sebb wrote:
On 29 April 2016 at 16:19, Josh Elser wrote:
> sebb wrote:
>> On 29 April 2016 at 15:59, Josh Elserwrote:
How does
Ralph Goers wrote:
On Apr 29, 2016, at 9:27 AM, Josh Elser wrote:
sebb wrote:
On 29 April 2016 at 16:19, Josh Elser wrote:
sebb wrote:
On 29 April 2016 at 15:59, Josh Elserwrote:
How does changing the package name help? Doesn't that just push a
NoClassDefFound error instead of s
> On Apr 29, 2016, at 9:27 AM, Josh Elser wrote:
>
> sebb wrote:
>> On 29 April 2016 at 16:19, Josh Elser wrote:
>>> sebb wrote:
On 29 April 2016 at 15:59, Josh Elser wrote:
>> How does changing the package name help? Doesn't that just push a
>> NoClassDefFound error instead of
sebb wrote:
On 29 April 2016 at 16:19, Josh Elser wrote:
sebb wrote:
On 29 April 2016 at 15:59, Josh Elser wrote:
How does changing the package name help? Doesn't that just push a
NoClassDefFound error instead of some missing implementation for a new
method?
That means we change ALL
On 29 April 2016 at 16:19, Josh Elser wrote:
> sebb wrote:
>>
>> On 29 April 2016 at 15:59, Josh Elser wrote:
>>>
>>> > How does changing the package name help? Doesn't that just push a
>>> > NoClassDefFound error instead of some missing implementation for a new
>>> > method?
>>
>>
>> That mea
sebb wrote:
On 29 April 2016 at 15:59, Josh Elser wrote:
> How does changing the package name help? Doesn't that just push a
> NoClassDefFound error instead of some missing implementation for a new
> method?
That means we change ALL the package names and the Maven coords.
Effectively it's
On 29 April 2016 at 15:59, Josh Elser wrote:
> How does changing the package name help? Doesn't that just push a
> NoClassDefFound error instead of some missing implementation for a new
> method?
That means we change ALL the package names and the Maven coords.
Effectively it's a different compone
How does changing the package name help? Doesn't that just push a
NoClassDefFound error instead of some missing implementation for a new
method?
Where do you all define what is public API (and thus what is stated to
be stable)?
Gary Gregory wrote:
We have 2 choices IMO: document breaks or c
We have 2 choices IMO: document breaks or change package name. The later is
safer from a jar hell POV.
The question is how likely are the changes going to break BC IRL? There are
two main use cases: user like call sites and implementors of providers.
Thoughts?
Gary
It looks like there are about
It looks like there are about 7 areas in core/ where compatibility
against 2.0 has been broken:
* Methods added to o.a.c.v.{FileContent,FileName,FileObject}
* Method added to o.a.c.v.RandomAccessContent
* Parameters changed on method(s) in
o.a.c.v.p.{b.Bzip2FileObject,g.GzipFileObject}
* Chang
18 matches
Mail list logo
