Return-Path: Delivered-To: apmail-jakarta-struts-dev-archive@apache.org Received: (qmail 23271 invoked from network); 12 Oct 2002 17:34:55 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 12 Oct 2002 17:34:55 -0000 Received: (qmail 3743 invoked by uid 97); 12 Oct 2002 17:35:40 -0000 Delivered-To: qmlist-jakarta-archive-struts-dev@jakarta.apache.org Received: (qmail 3707 invoked by uid 97); 12 Oct 2002 17:35:39 -0000 Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list struts-dev@jakarta.apache.org Received: (qmail 3695 invoked by uid 98); 12 Oct 2002 17:35:39 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) X-Server-Uuid: 6E802067-ECFC-4FC2-A617-DD5220DD9CBB Message-ID: <7382FCA44E27D411BD4A00508BD68F95053CD3F7@pigeon.tumbleweed.com> From: "Martin Cooper" To: "'Struts Developers List'" Subject: RE: [Policy on depreciation vs deleting new Struts 1.1 methods.] Date: Sat, 12 Oct 2002 10:32:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 11B6819B267577-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I agree with Ted and James - even if I'm not writing a book. ;-) We should zap the new-and-already-obsolete stuff now, and not perpetuate it. Deprecation, IMO, should only be used for things that have already appeared as part of a stable release. (Depreciation, on the other hand, I'll leave for James and his 20 Yen. :) -- Martin Cooper > -----Original Message----- > From: Rob Leland [mailto:rleland@apache.org] > Sent: Friday, October 11, 2002 11:05 PM > To: struts-dev@jakarta.apache.org > 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: > > For additional commands, e-mail: > > > -- To unsubscribe, e-mail: For additional commands, e-mail: