RE: [Policy on depreciation vs deleting new Struts 1.1 methods.]
I disagree. The most useful method of timing releases for both developers and users Is when the features reach critical mass. That way it is worth the effort for the developers to release and the users to upgrade. Edgar The real underlying problem, which we should address in post 1.1, is that our releases have become too coarsely grained. Moving past 1.1, we should try to release whenever a significant feature is added, rather than when the features reach some critical mass. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Policy on depreciation vs deleting new Struts 1.1 methods.]
Have we ever included it in a beta release? If so, deprecation is definitely the right answer. If not, how long has it been around? If only a short while, I'd say go ahead and remove it. Craig On Sat, 12 Oct 2002, Rob Leland wrote: Date: Sat, 12 Oct 2002 02:05:09 -0400 From: Rob Leland [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Policy on depreciation vs deleting new Struts 1.1 methods.] I same across a method in Action that didn't use one of its parameters, it was added in struts 1.1 the comment said. Since it was added in the 1.1 Time Frame do we: A) Immediately remove it or B) Depreciate the method and remove it later. My preference would be to remove it before the final Struts 1.1 is released, but can we remove it before the next beta ? - depreciated validator methods, js -- In a similar more specific note, in the validator JavaScript I added a floatRange() method, and duplicated the range() method and called it intRange() for JavaScript. For Java I added validateIntRange() and validateFloatRange(), and depreciated range(). I would hate to piss off the people who buy Chuck's and Ted's books, too much ;-) ! So what is the feeling on handling this. The next version of the books will probably take at least 12 - 18 months, and I would hate to wait that long since we just added the validator to struts this go around! Also maybe a new page needs to be created to document potential incompatabilities. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Policy on depreciation vs deleting new Struts 1.1 methods.]
At 02:05 AM 10/12/2002, you wrote: I would hate to piss off the people who buy Chuck's and Ted's books, too much ;-) ! So what is the feeling on handling this. The next version of the books will probably take at least 12 - 18 months, and I would hate to wait that long since we just added the validator to struts this go around! My 20 yen* on the subject: All of us folks with Struts books either out or due out soon know that we're describing a work in progress. There are several places in the Struts book that Kevin and I are writing that we essentially say this hasn't settled down yet, and I was updating the chapter on the Validator this week, and may have to revise it again next week, with final galleys due in 2 weeks... I know my publisher (SAMS), and most of the other tech publishers maintain web sites for their books, where the authors can post agendums post publication. I have already planned to have to do a what changed in the 1.1 final release document once that release finally hits the pavement. If it were me, I'd change what I needed to change to make the code right. James * - Subject to currency fluctuations. Past performance is not an indication of future returns. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
