commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject [VFS] Analysis of binary compatibility breaks between 1.0 and 2.0; release strategy
Date Tue, 16 Nov 2010 21:21:43 GMT
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message