commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [fileupload] RFC: Fileupload 1.3 or 2.0?
Date Tue, 03 Jul 2007 20:04:23 GMT
Jochen Wiedmann wrote:
> when applying the fixes for IO-99 to commons-fileupload, I was
> originally under the impression, that this would be easily possible
> without any or at least with fully upward compliant API changes.
> Until I detected that for reasons, which absolutely escape me, someone
> made FileItem to implement the Serializable interface.

I've read the JIRA's and I don't understand why FileItem/Serializable is 
relevant. As such I'm struggling to understand this thread :-)

> The longer I thought about it, the more I came to the conclusion, that
> the only clean solution is to accept API changes. In particular, let
> FileItem no longer implement the Serializable interface. While we are
> at it, we could as well dissolve the the FileItemFactory and the
> multipart parser. Remove the whole bunch of deprecated methods.
> In other words, I propose to resolve FILEUPLOAD-120.or FILEUPLOAD-125
> finally by dropping binary compatibilty and declaring the next version
> as commons-fileupload 2.0, not 1.3.

OK, here is my view on this (I'll get in early this time).

If there is a minor incompatible change, like making FileItem no longer 
implement Serializable, then IMO that can be a v2.0 with the same 
package name. (Minor means that it has no effect on the vast majority of 
users. In addition, deprecated methods and classes can be removed.

If there are larger changes that involve design changes, especially 
changes to user code (backwards imcompatible) then that should be a v2.0 
with a different package name.

If you choose the latter option, I would personally prefer to see 
[fileupload] move to Java 1.5 at the same time.


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

View raw message