in reply to Re: RFC: CGI::Uploader V 2.90_01
in thread RFC: CGI::Uploader V 2.90_01
Hi ysth
The original module was idiosyncratically written and badly documented, and contained various hard-coded decisions.
Vast changes were made, based on what I wanted the module to do, compared to what it used to do.
The list of changes is not so important, actually.
What's important now is to study the new docs and decide if the module does in fact provide a user-friendly upload mechanism.
|
Re^3: RFC: CGI::Uploader V 2.90_01
by Popcorn Dave (Abbot) on Dec 01, 2008 at 20:43 UTC
|
"Vast changes were made, based on what I wanted the module to do, compared to what it used to do. The list of changes is not so important, actually."
While I agree that it's useful for people to see if your interface is user friendly, to say that the list of changes isn't important seems to fly in the face of everyone using the original module doesn't it? If they're happy with the old module, why should they change without seeing the list of changes you've made?
To disagree, one doesn't have to be disagreeable - Barry Goldwater
| [reply] |
|
|
I see your point.
I was concerned that the changes would be assessed in a tiny-point by tiny-point manner, which would obscure the view of the overall redesign.
Also, I want people using the previous version to stop and think about their app design, not just expect that a couple of lines need to be changed.
That's why the version has jumped to 2.90* in preparation for release as V 3.
| [reply] |
|
|
If you have rewritten and broken backwards compatibility, and you don't know of/don't care about the migration of existing users (I hear you saying, if it doesn't work then their design is bad and thus their fault), why not make it a new module entirely or a subclass? I'd be upset if I upgraded a module and found it was wildly different, requiring me to rewrite my app if I wanted to use it.
| [reply] |