I would be absolutely -1 on doing things differently just because people (like me) are writing books. As James mentioned, we all know writing about unreleased software is a dangerous job =;0)
I'd say the difference between nightly-build/beta and a release is that in the former we tend to delete or rename and in the later we almost always deprecate first. One good reason for that is that any given beta could be promoted to a release candidate, voted upon, and then released. The goal should be to create a beta that we could vote to release untouched. If we deprecate between betas, then we beg the question of yet-another-beta. I couldn't find the code we're talking about here, but my only question would be whether the parameter was added for the benefit of some ancestor class. 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. Rob Leland wrote: > 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]> > > -- Ted Husted, Husted dot Com, Fairport NY US co-author, Java Web Development with Struts Order it today: <http://husted.com/struts/book.html> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
