[vfs] next release minor or major version?

[Bernd Eckenfels <ec...@zusammenkunft.net>]

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

RE: [vfs] next release minor or major version?

[dl...@comcast.net]

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 [mailto:ecki@zusammenkunft.net] 
Sent: Friday, December 19, 2014 5:48 PM
To: dev@commons.apache.org
Subject: [vfs] next release minor or major version?

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/6126df98f9ecbb324b3bafaf401bbe
2e03103c1e#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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org