Hello, 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 (AbstractRamdomAccessContent,MonitorRandomAccessContent) 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 HttpFileProvider (https://github.com/apache/commons-vfs/commit/6126df98f9ecbb324b3bafaf401bbe2e03103c1e#diff-367794f3f87aa4a90d6e8c4b9fe16003)) 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? Gruss Bernd --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
