commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <>
Subject RE: [FileUpload] Changes committed
Date Sun, 27 Apr 2003 23:56:10 GMT

On Mon, 28 Apr 2003, Thierry De Leeuw wrote:

> Martin,
> To ease the development and the maintenance, is it possible to
> * have only one bug fix or enhancement per revision. (easier if there is a
> need to rollback and if someone wants to see the implementation of a
> specific change)

This is generally how things are done. However, in this case, it would
have been more work to *not* fix some of the bugs as the code was being
reworked to accommodate the larger changes. The main reasons that the
commit message was too large was because there are several new classes
required to fix the problems, and because some existing classes were

> * create a bug report for every change applied and
> 	- take the bug number as reference in the revision comment. (easy to find
> what was the purpose of a change later on)
> 	- update the bug record to mention what files were impacted and which
> revision implements the change.

If the people who report the bug file a bug report, then I update the bug
reports when the bugs are fixed. If they don't file a bug report, then I'm
not likely to spend my time doing it. Bug reports are updated with the
date of the nightly build within which they are fixed.

> To mark a release, a simple tag can do it.

Releases are always tagged.

Martin Cooper

> Just my 2 cents.
> Best regards,
> Thierry De Leeuw
> -----Original Message-----
> From: Martin Cooper []
> Sent: dimanche 27 avril 2003 19:41
> To:
> Subject: [FileUpload] Changes committed
> I've committed the bulk of the changes for FileUpload 1.0 Beta 2, but the
> commit message was rejected because it was too big, so here are the notes
> from that message:
> Changes to support more general extensions of FileUpload, better control
> over individual upload requests, and better error handling.
>  - Split out disk-based repository implementation from a generic
>    implementation that does not make assumptions about how uploaded files
>    are stored (or even if they are). Most clients should now use
>    DiskFileUpload rather than the more generic FileUpload.
>  - Use a factory to create new file items, thus permitting the factory
>    to be configured independently of FileUpload, and the file items to be
>    provided with more context (for example, a database connection).
>  - The size threshold now applies to individual form items, rather than
>    to the request as a whole. (PR #17044, reported by Faustas Zilinskas)
>  - Resolve several path and file name issues related to individual file
>    items. (PR #17872, reported by Brent Verner)
>  - Catch and handle specific exceptions, rather than generic ones.
>    (PR #18265, reported by David Graham)
>  - New unit tests for new and changed functionality.
>  - Minor documentation updates (although more are needed).
> --
> Martin Cooper
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message