commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: [vfs] next release minor or major version?
Date Sat, 20 Dec 2014 01:01:15 GMT
I have not forgotten about the todo list. Have been swamped at work and hope
to get some of it done over the holidays.

-----Original Message-----
From: Bernd Eckenfels [] 
Sent: Friday, December 19, 2014 5:48 PM
Subject: [vfs] next release minor or major version?


sorry for coming back to this topic, but I did not really received any
oppinions or help on it, and I really want to do a release.

I would like to release the VFS trunk as 2.1, because it contains a lot of
bug fixes and is asked for by people. If we decide to release it as
3.0 (with the changed packages) it will do a dis-service to people, as they
cannot use it as a drop in bug fix.

So I made a Spreadshet of the Clirr report, to see if any of the changes to
the interfaces are actually critical. How can we proceed with this, can I
ask for a Vote if you think it is fine to go with 2.1?

I think no consumer of the VFS Implementation is affected by those changes,
and most providers who use proper abstract classes (and not access existing
providers directly) will be affected.

There are 28 Clirr Errors:

Affecting Service Providers;

4 Methods on FileContent (in DefaultFileContent)
1 Method  on FileName    (in AbstractFileName)
8 Metods  on FileObject  (in AbstractFileObject, DecoratedFileObject)
2 Methods on FileSystemManager (in DefaultFileSystemManager)
1 Method  on RandomAccessContent

For FileObject (MimeFileObject) and RandomAccessContent
(RamfileRandomAccesscontent, RACRandomAccessFile) there are implementations
which do not directlry extend Abstract* supertypes.

The other changes are in the provider classes. They do not really belong to
the API but on the other hand, we cannot gurantee that they are not used
anyway. Mostly changed parameter types and return types.

TarFileObject.entry is private now and changed semantic, that (together with
setTarEntry()) is most likely the most problematic change?

The AUTHENTICATOR_TYPE seems to be a false positive, as it is inherited from

I would add a caveat to that extent do release(notes), but go with 2.1, what
do others think?

How can I get a decision on this before starting a release vote? Can I ask
for a vote on this or get a decision from PMC?


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message