+1 on rename and deprecation. David
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: Modules vs. Sub-Applications
Date: Mon, 28 Oct 2002 21:48:05 -0800 (PST)
On Tue, 29 Oct 2002, Rob Leland wrote:
> Date: Tue, 29 Oct 2002 00:27:11 -0500
> From: Rob Leland <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Modules vs. Sub-Applications
>
>
>
> Ted Husted wrote:
>
> > As these methods are really not part of the public API, could
> > we not just change them now and be done with it?
>
>
> Some are Public, however I would also vote
> +1 to rename them now.
>
> I agree with David and say lets go one intermediate
> step and deprecate them
> for struts 1.1B3 but to remove them before
> the next beta or Release candidate.
>
> That is what I propose to do with the
> StrutsValidator & StrutsValidatorUtil
> methods.
>
> This would not effect compatability between
> 1.0 & 1.1 and would give a grace period to people
> using the Beta3 or Nightly builds.
> If a user tries to upgrade to the final struts 1.1
> build, we could always suggest first going to the 1.1B3
> removing the deprecation warnings then going to 1.1 final.
>
I've come around to +1 on the rename+deprecation, but I'm not OK with
removing the old ones in 1.1 final. Reasoning: we did a public release
(1.1b2) with these APIs. If we'd only done nightlies, I would be OK with
the removal.
We can do a cleanup of deprecated stuff after 1.1 final and before the
first 1.2 milestone, similar to what we did after 1.0 and before 1.1b1.
Does that make sense?
> -Rob
Craig
>
> >
> >
> > -Ted.
> >
> > 10/28/2002 1:21:40 PM, "Craig R. McClanahan"
> > wrote:
> >
> >
> > >
> > >On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote:
> > >
> > >
> > >>I thought it was application module, therefore the
> > >>current names are still consistent with that.
> > >
> > >That's certainly my excuse for thinking we should not change
> >
> > them now :-).
> >
> > >Although I agree with David that ModuleConfig and selectModule
> >
> > () would
> >
> > >have made more sense had we known this was going to be the
> >
> > conclusion.
> >
> > >Craig
> > >
> > >
> > >>Did I miss
> > >>some threads :(
> > >>
> > >>Wait, stop the printer...
> > >>
> > >
> > >Ah, the perils of writing about beta software :-) :-)
> > >
> > >
> > >>chuck
> > >
> > >Craig
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
> >
> > >For additional commands, e-mail:
> >
> > >
> > --
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
> >
>
>
>
> --
> To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
_________________________________________________________________
Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
