Clirr reports the following problems when comparing the codebases (prior to the vfs2 package rename)
1) Selectors: Changed from interface to class This contains only constants. The interface was not actually implemented by any VFS classes; the constants were referenced using the class name If any user classes were lazy and implemented the interface rather than using the qualified name, then they would break. But this seems rather unlikely. 2) util.UserAuthenticatorUtils: Added final modifier to class - class has static methods only, so no point in sub-classing it 3) FileSystemOptions: Added final modifier to class - this class appears to be internal use only 4) provider.HostFileNameParser$Authority: Accessibility of field hostName has been weakened from public to private provider.HostFileNameParser$Authority: Accessibility of field password has been weakened from public to private provider.HostFileNameParser$Authority: Accessibility of field port has been weakened from public to private provider.HostFileNameParser$Authority: Accessibility of field scheme has been weakened from public to private provider.HostFileNameParser$Authority: Accessibility of field userName has been weakened from public to private - These are all changes to a protected nested class; seems to be internal use only 5) FileSystemConfigBuilder: Accessibility of method 'public FileSystemConfigBuilder()' has been decreased from public to protected This is the default ctor of an abstract class. The other ctor was already protected. User code should not be instantiating this class directly. 6) util.UserAuthenticatorUtils: Accessibility of method 'public UserAuthenticatorUtils()' has been decreased from public to private This is a class with static methods only; it should never be instantiated 7) FileContent: Method 'public boolean hasAttribute(java.lang.String)' has been added to an interface FileContent: Method 'public void removeAttribute(java.lang.String)' has been added to an interface There is a single implementation: DefaultFileContent 8) FileSystem: Method 'public java.lang.String getRootURI()' has been added to an interface There is an AbstractFileSystem class which all other VFS implementations subclass. 9) FileSystemManager: Method 'public boolean hasProvider(java.lang.String)' has been added to an interface There is a DefaultFileSystemManager which is the most likely route for any 3rd party implementations. These 3 interfaces are part of the public API as far as I can tell. However, would user code ever directly implement the interfaces? == It looks to me as though user code is very unlikely to be affected by any of the binary changes. The only changes that might perhaps affect user code are 1), 7), 9) and possibly 8) Also, the latest Gump run of vfs 1.x (which is actually using the SVN code commons/proper/vfs/tags/preVFS2package temporarily) does not have any dependee failures (apart from Doxia which fails for an unrelated reason). I think it would be safe to release 2.0 using the package o.a.c.vfs (rather than vfs2). [It needs to be 2.0 because of the API changes and there are a lot of new providers etc.] However this would mean reverting to the old groupId (unless we can be sure that relocation POMs work). [Note: The recent StringBuilder changes can be made backwards-compatible by adding back the old API methods]. As I see it, there are the following options: 1) Release 2.0 as described above. Upside: no need for downstream users to update their code. Downside is the change to o.a.c groupId may not be possible. Slight risk of user API break. 2) Release 2.0 using vfs2 and groupId o.a.c Upside: Can fix groupId. No need to maintain any API compatibility; can drop all deprecated code. Downside: All downstream users need to recode their applications. If the consensus is to stick with VFS2 and option 2, then I think we need to look very carefully at the code to ensure that there aren't any areas of the code that would benefit from an API change. In particular, we should delete all deprecated code. Otherwise there might have to be VFS3 which would force all downstream users to recode their applications yet again. Or perhaps we could release an ALPHA or BETA version, with the proviso that the API might change when the final version is released? At least then downstream users would be warned. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
